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ABSTRACT 

This  report  contains  assessments  of  the  Joint  Medical  Operation,  Telemedicine  components  introduced  and 
exercised  during  Fleet  Battle  Experiment-India.  Appendix  1  contains  raw  notes  of  observations  taken  during  the 
exercise.  It  contains  detailed  chronological  observations  which  form  the  basis  for  the  assessment.  Appendix  2  is  a 
report  by  the  CNA  analyst  discussing  her  observations  and  findings  for  the  same  exercise.  It  contains  more  thorough 
technical  details  from  the  perspective  of  the  observer  resident  aboard  the  USS  Coronado  during  the  exercise. 

The  general  conclusion  is  that  the  elements  of  JMO-T  exercised  during  FBE-I  show  great  potential.  However, 
details  need  more  careful  work  and  evaluation  before  operational  utility. 
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Introduction: 

Joint  Medical  Operations  -  Telemedicine  (JMO  -  T),  is  an  Advanced  Concept 
Technology  Demonstration  (ACTD),  whose  purpose  is  to  facilitate  operational  and 
administrative  aspects  of  medical  care.  The  JMO-T  was  used  with  the  Extended  Littoral 
Battlefield  (ELB)  WARNET  as  the  communications  link.  Its  operation  was  observed 
from  four  locations  during  Fleet  Battle  Experiment  -  India,  FBE-I. 

Our  assessment  of  the  overall  system  is  derived  from  direct  observation  of  its 
field  use  during  Marine  Amphibious  Landing  Beach  at  Camp  Pendleton;  Fleet  Combat 
Training  Center,  Pacific  at  San  Diego;  3^^  Marine  Expeditionary  Unit  (MEU)  at  the 
Marine  Corps  Tactical  Support  Systems  Activity  (MCTSSA)  and  on  the  USS  Coronado. 
A  complete  view  of  JMO-T  was  not  available  to  any  one  user,  and  different  functional 
views  were  seen  at  each  location.  We  observed  the  hardware;  examined  the  software 
interfaces;  spoke  with  military  users,  contractor's  installers,  program  designers  and 
managers;  read  contractor  provided  system  and  component  literature;  and  observed  the 
systems  being  used.  Our  assessment  is  more  in-depth,  by  being  at  four  different 
locations,  than  could  have  been  obtained  from  a  single  location. 

The  descriptions  of  the  JMO-T's  elements  are  in  terms  of  their  functional 
relationships,  as  observed.  Since  we  were  not  privy  to  the  design  architecture  and 
technologies  of  the  system,  the  details  may  differ  from  the  manufacturer  or  program 
intent. 


Key  elements  of  the  JMO-T  observed  were: 

Extended  Littoral  Battlespace  (ELB)  WARNET 

The  ELB  WARNET  is  a  communication  network,  which  allows  small 
units  to  communicate  with  their  central  command.  The  basic  architecture  consists 
of  an  end  user  terminal  (EUT),  a  communication  van,  an  airborne  relay  terminal 
(e.g.  UAV,  helicopter,  satellite),  and  a  receiver  at  the  command  terminal. 
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Medical  Data  Surveillance  System  (MDSS) 

The  MDSS  objective  is  to  monitor  data  input  into  the  SAMS  patient 
database  and  is  a  decision  making  aide  to  the  Joint  Task  Force  Surgeon.  It 
enables  trends  in  symptoms  and  disease  to  be  highlighted  for  epidemiological 
purposes. 

Medical  Workstation  (MeWS) 

Watchboard  provides  a  collaborative  planning  and  reachback  support 
database;  Annex  Q,  operational  area  reporting  (medical  logistics  information, 
number  of  beds,  etc.);  and  patient  tracking  information,  and 

Database  Server,  which  provides  input  that  accepts  SAMS  patient  data, 
stores  data,  transfer  and  communications  capabilities. 

Shipboard  Automated  Medical  System  (SAMS) 

The  SAMS  is  a  shipboard  system  used  to  document  patient  encounters. 

Team  Care  Automation  System  (TCAS) 

TCAS  is  effectively  an  email  message  system,  which  allows  for 
communications  between  outlying  units  and  the  command  unit. 

Although  the  Joint  Medical  Operations-Telemedicine  shows  great  promise,  details 
in  design,  interface  issues  and  implementation  problems  demonstrate  it  is  not  ready  for 
operational  adoptions.  Certain  elements  are  useful  and  can  be  implemented  almost 
immediately,  but  these  useful  elements  are  not  strictly  products  of  the  JMO-T.  We  will 
discuss  various  aspects  separately  and  tie  them  together  so  that  their  functional  and 
mechanical  features  can  be  better  appreciated. 

Network  and  Communication  Link 

Perhaps  the  most  challenging  and  limiting  aspect  of  JMO-T  is  in  the  networking 
and  communications  links,  including  database  incompatibilities.  JMO-T  is  based  upon 
tying  together  commercial-off-the-shelf  (COTS)  components  to  achieve  military 
functionality.  As  consequence,  the  primary  task  for  the  contractor  community  is  to 
provide  database  translators,  so  one  useful  software  program  can  communicate  with 
another.  There  is  no  over-all  design  standard,  so  that  some  of  the  database  transfers  are 
effectively  diodes  and  can  transmit  only  in  one-way  communication.  The  inherent 
database  incompatibility  creates  awkwardness  in  implementing  relatively  simple  features, 
which  would  be  useful  to  the  fleet  surgeon  and  to  the  end  users  in  the  field. 

CHAT  and  Email  capabilities 

The  ability  to  engage  in  two-way  communication  may  be  one  of  the  most  useful 
aspects  of  JMO-T.  Common  text  can  be  transmitted  via  ELB  WARNET,  but  continuity 
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of  user  participation  is  essential.  The  prior  incoming  message  is  not  preserved.  So, 
incoming  and  outgoing  messages  are  segregated  in  different  files.  Consequently,  if  a 
simple  query  such  as  "What  is  the  temperature  in  El  Centro?",  would  evoke  the  response 
"101".  If  there  is  other  communication  between  the  query  and  the  response,  or  if  another 
replaces  the  user  in  one  location,  then  the  train  of  the  conversation  is  lost.  It  is 
understandable  that  the  CHAT  content  must  be  short,  but  at  least  in  the  command  center, 
the  ability  to  combine  incoming  and  outgoing  message  by  time  would  allow  at  least  the 
command  center  to  easily  follow  the  conversation. 

In  addition  to  written  queries,  voice  communication  is  essential.  In  one  example, 
a  real  heat  stress  case  appeared  in  the  situational  awareness  map  of  El  Centro.  At 
MCTSSA  which  was  monitoring  the  battlefield  situational  awareness  map,  it  was  not 
known  to  the  Marine  lieutenant  colonel  whether  this  medical  event  was  real  or  simulated, 
nor  whether  it  occurred  that  day  or  was  a  left-over  mark  from  the  previous  day  and 
whether  assistance  was  requested.  Written  CHAT  communication  was  not  available  and 
only  the  situational  awareness  map  indicator  was  readily  available  to  the  monitoring 
officer.  It  was  through  radio  communication,  using  the  satellite  based  PC2  voice 
communication  device,  that  it  was  confirmed  that  the  event  was  real  and  not  simulated. 
This  took  over  an  hour  to  resolve  from  the  first  inquiry.  As  observed,  only  one-way 
CHAT  capability  was  effectively  available. 

Imagery 

The  present  form  of  JMO-T  is  primarily  for  message  and  SAMS  data 
transmission.  Although  not  part  of  the  present  system,  the  ability  to  convey  imagery  is 
very  helpful  for  diagnosis  in  the  field.  A  crewman  on  the  USS  Bunker  Hill  sustained  an 
eye  injury  and  the  corpsman  onboard  requested  air  medical  evacuation  during  the 
exercise.  The  fleet  surgeon  was  able  to  obtain  a  picture  of  the  eye  injury  as  a  normal 
email  attachment  and  the  surgeon  was  able  to  diagnose  the  injury  as  non-critical  and  a 
medevac  into  the  exercise's  congested  air  space  was  avoided. 

Presently,  telemedicine  is  possible  even  with  the  use  of  the  currently  available 
email  capability.  At  each  unit  with  this  capability,  instant-imaging  capability  should  be 
provided.  The  availability  of  digital  cameras  should  make  image  transmission  a 
possibility.  The  question  is  the  availability  of  sufficient  bandwidth. 

Because  the  USS  Bunker  Hill  is  a  large  combatant,  the  communication  capability 
was  robust  enough  to  allow  two  way  image  transmission.  Although  desirable,  there 
probably  is  not  sufficient  bandwidth  currently  to  allow  this  type  of  communication  for  a 
jump  team  in  the  field.  However,  as  technology  improves,  the  image  conveyance  should 
soon  become  possible  for  a  battle  aid  station,  where  medevac  and  triage  decisions  may  be 
aided  considerably  with  better  educated  medical  expertise. 

Database  Issues 
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SAMS  data  entry  from  the  field  is  a  tedious  process.  Corpsmen  and  medics  in  the 
jump  team  took  about  twenty  minutes  to  populate  each  entry  in  the  databases  in  the 
present  end  user  terminals  (EUT).  Part  of  this  is  because  there  are  fields  which  require 
diagnosis  judgment  by  the  EUT  user,  e.g.  Subjective  (paragraph  for  description  or 
diagnosis)  and  Objective  (patient  entry  evaluation  according  to  injury). 

Changes  that  would  make  the  system  more  useful  are  as  follows: 

a)  The  entries  into  the  data  field  can  be  made  different  depending  on  what 
function  the  end  user  is  fulfilling.  The  requirements  for  a  jump  team  are 
different  from  a  battalion  aid  station  or  a  naval  vessel,  e.g.  the  USS  Bunker 
Hill. 

b)  Modifications  of  the  entry  data  field  could  make  the  EUT  small  enough  for 
use  by  a  forward  jump  team  and  in  the  case  where  Medevac  is  being 
requested,  a  smaller  device,  such  as  a  palm  pilot  could  be  used.  This 
miniaturization  of  the  end  user  terminal  would  make  it  a  practical  piece  of 
field  equipment. 

c)  The  data  field  should  be  compatible  for  both  receipt  and  sending  by  the  end 
user.  This  would  allow  for  later  completion  of  the  SAMS  data  entry  when 
immediate  operational  conditions  would  allow  for  more  leisurely  reflection 
and  entry  by  the  end  user.  (This  modification  would  require  extensive  work 
by  the  contractor  to  make  data  fields  compatible.  Currently,  for  the  MDSS 
and  for  SAMS,  different  databases  are  used  since  they  are  COTS  products.) 

d)  The  MDSS  will  probably  be  used  for  large  population  bases  such  as  in  joint 
and  combined  operations  such  as  Humanitarian  relief  operations.  The 
scenario  scripted  for  FBE-I  was  a  refugee  population.  To  be  useful  for  such 
operations,  two-way  communication  is  essential.  The  goals  and  needs  of  the 
US  military  users  may  be  considerably  different  from  that  of  other  United 
States  agencies,  even  disregarding  the  different  agendas  of  international  and 
non-govemmental  organizations.  The  availability  of  security  considerations 
have  yet  to  be  fully  thought  out. 

Other  issues  which  need  to  be  considered  involve  decisions  as  for  whom  the  total 
JMO-T  system  should  be  useful:  For  example,  in  monitoring  refugee  camps,  the  MDSS 
system  needs  to  be  able  to  aggregate  information  for  different  times  and  for  different 
populations.  The  Joint  Forces  Commander  probably  would  not  need  nor  want  the 
incidence  of  particular  symptoms  on  an  hourly  or  daily  basis,  but  might  find  the 
information  useful  on  a  weekly  or  monthly  basis.  In  monitoring  for  the  possibility  of  an 
epidemic  or  biological  attack,  the  military  commander  may  need  the  information 
segregated  by  units  or  other  characteristics.  The  fleet  surgeon  or  epidemiologist  may 
want  the  ability  to  monitor  other  groupings,  such  as  date  of  arrival  or  by  blood  types.  It  is 
doubtful  that  all  required  groupings  could  be  pre-determined.  So,  the  fleet  surgeon 
should  have  the  ability  to  cross  correlate  any  column  of  entry  into  the  SAMS  database 
against  any  other.  Currently,  the  COTS  databases  do  not  allow  this  flexibility. 

Another  issue  that  needs  to  be  addressed  is  the  issue  of  "Saving  Private  Ryan," 
finding  a  person  in  a  large  group.  The  present  system  cannot  handle  large  databases  for 
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search  processes.  In  certain  situations,  such  as  for  the  search  of  a  particular  name  in  a 
population  of  Hawaiians,  Chinese,  or  Korean  names,  the  present  search  capabilities  are 
overloaded  (This  is  because  there  are  only  a  finite  number  of  these  names.).  Search 
capabilities  based  upon  other  characteristics,  date  of  entry  into  the  database,  blood  type, 
location,  unit,  etc.  would  alleviate  this  situation. 

The  SAMS  database  has  been  designed  for  hospital  administrative  purposes  and  is 
not  particularly  compatible  with  battlefield  injury  situations.  The  modules  should  be 
reconsidered  for  battlefield  situations.  This  may  require  consideration  of  encounter 
entries. 

Test  and  Assessment  Considerations 

There  is  too  much  compartmentalization  in  software  and  elsewhere.  For  example, 
the  designer  of  Watchboard,  have  one  client  in  mind,  but  there  are  other  users. 

Contractors  tend  to  work  only  on  the  scope  of  the  contract.  Some  independent 
assessment  is  needed  to  identify  changes,  which  would  accommodate  the  universe  of 
users.  The  present  evaluators  are  concerned  with  the  subjective  elements  of  the  hardware 
and  software.  Their  emphasis  is  evaluating  JMO-T  as  a  "black  box"  in  its  present  form. 
More  emphasis  needs  to  be  made  on  the  evaluation  of  the  technical  military  aspects. 

For  example,  it  was  not  until  the  end  of  the  exercise  that  we  were  able  to 
understand  that  many  of  the  shortcomings  came  because  the  program  is  based  on  a  COTS 
emphasis.  As  a  COTS  product,  the  databases  are  not  created  to  be  inherently  compatible. 
The  contractor's  responsibility  is  effectively  to  provide  one-way  translators  from  one 
software  vendor's  database  to  another.  As  a  consequence,  two-way  transfers  are  not 
possible. 

The  present  concept  is  to  have  help  teams  consisting  of  resources  at  some 
designated  on-shore  station  and  a  contractor  stationed  at  the  BUT  location,  e.g.  riding 
aboard  the  command  ship.  Every  time  military  personnel  encountered  a  problem, 
whether  minor  or  major,  in  using  the  JMO-T  software,  the  contractor  representative 
immediately  stepped  in  to  help  resolve  the  problem.  From  an  operational  point  of  view, 
this  is  not  effective.  Military  gear  may  be  complicated,  but  the  interface  must  be 
sufficiently  simple  and  the  software  and  equipment  robust  enough  that  it  may  be  used  by 
military  personnel  without  on-the-spot  guidance. 

One  of  the  items  most  lacking  for  JMO-T  is  the  existence  of  a  useful  users' 
manual.  The  manual  needs  to  be  more  than  an  "idiot"  instruction  booklet,  and  needs  to 
have  exposition  concerning  philosophy  of  design,  history,  and  additional  capability, 
much  as  a  textbook  would  have.  The  present  situation  is  that  each  user  in  each  location 
has  a  view  of  the  JMO-T  as  viewed  through  a  narrow  straw  and  understanding  of  the 
whole  system  is  not  easily  available.  Without  observers  at  each  of  the  locations,  we 
would  not  have  known  what  was  happening.  A  common  operating  picture  or  philosophy 
was  not  easily  available  to  the  users  at  each  of  the  different  activities. 
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SUMMARY 


The  JMO-T  system  shows  tremendous  promise  for  field  use.  However,  in  its 
present  form  it  is  not  robust  enough  and  self  compatible  enough  within  its  entirety  to  be 
close  to  field  introduction.  Analysis  and  integration  of  the  system  from  the  perspective  of 
each  of  the  users  is  necessary.  Presently,  JMO-T  is  too  fragmentary  to  be  relied  upon  for 
use  by  the  military  in  an  operational  environment. 

Attached  are  our  raw  notes  on  observations  made  during  FBE-I .  (Appendix  1) 
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OBSEVATIONAL  NOTES  OF  JMO-T  DURING  FLEET  BATTLE  EXPERIMENT  -INDIA  AND 
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FLEET  BATTLE  EXPERIMENT  -  INDIA 
Assessment  of  JMOT 

15-18  May  2001 

USS  Coronado  for  KBX  wargames,  JMO-T.  Met  Kathleen  M.  Ward,  Center  for  Naval  Analyses, 
703-824-2029,  \vardk@cna.org.  She  was  inputting  scenario  into  the  MDSS  =  Medical  Data  Surveillance 
System.  One  problem  is  that  the  program  lumps  symptoms  so  that  many  diseases  of  concern  are  not 
differentiated.  E.g.  upper  respiratory  and  lower  respiratory  symptom  are  not  differentiated,  so  diseases 
such  as  anthrax  would  not  be  captured  and  highlighted. 

MDSS  is  useful  in  concept,  but  in  practice,  not.  The  ability  to  backtrack  and  display  groupings  at 
the  discretion  of  the  end  user  would  enhance  the  program  considerably.  For  example,  it  should  be  possible 
to  display  analyzed  and  semi-analyzed  data  before  and  after  any  program  filters  are  applied.  The  trouble 
shooting  should  have  been  done  by  the  program  developers,  not  NWDC. 

JMOT  telephone  numbers,  Young  01-102-2,  7613;  McCartin,  5115;  Hancock,  5124.  The  program 
is  supposed  to  be  compatible  with  NDRS  =  Naval  Disease  Reporting  System  maintained  by  NEHC  =  Navy 
Environmental  Health  Center. 

Story  Board:  Purpose  of  Epidemiology;  Detection  of  Disease  Trends  in  the  Population; 
Identification  of  Specific  Diseases  in  Population;  Discrimination  between  Epidemic  and  Biological  Attack; 
Provide  Information  to  Decision  Makers  for  Action. 

FBE-I:  18  June  depart;  25  June,  return  to  port;  30  June,  end  of  exercise, 

MeWS,  watchboard;  user  Administrator;  password  NHRDCSAIC 

I  will  be  at  Fleet  Combat  Training  Center  Pacific,  (FCTCPAC) 

18  Jun  2001 

FBE-I.  Fleet  Battle  Experiment-India.  Stationed  at  Fleet  Combat  Training  Center,  Pacific 
(FTCPAC).  LCDR  Krissa  Baylor  is  a  Navy  reservist  (Aerospace  Physiologist)  from  the  Bay  Area.  Her 
home  telephone  number  is  408-238-7065  and  her  email  is  kbavlor(g)musd.org.  CDR  Rod  Abbott  (Physicist) 
who  works  at  Livermore  is  the  Operations  Officer  for  their  reserve  unit  and  is  also  at  FTCPAC.  Rod’s 
telephone  number  at  LLNL  is  410-422-4410  and  his  email  is  abbott4@llnl.gov. 

Before  USS  Coronado  left  port,  Krissa  and  I  visited  the  ship.  We  made  contact  with  John 
Wolthuis  who  is  the  Medical  Data  Surveillance  System  (MDSS)  so^are  technician,  Cynthia  Kramer  who 
is  the  SAIC  technologies  technician,  LCDR  Michelle  Hancock  who  is  the  Deputy  Fleet  Surgeon  onboard 
the  USS  Coronado,  and  Dr.  Kathleen  Ward  from  the  Naval  Warfare  Development  Command  (NWDC)  who 
is  the  medical  scenerio  developer  for  FBE-I  and  who  will  provide  ddata  to  test  the  MDSS  developed  under 
the  sponsorship  of  DARPA-NEHC. 

Upon  return  to  FCTCPAC,  there  was  no  CHAT  communication  concerning  medical  activity. 

CHATline:  when  communication  drops  out,  we  lose  the  chat  during  the  time  of  communication 
loss  the  chat  is  stored  in  the  server,  but  because  of  loss  of  communication,  the  operational  linkage  cannot 
easily  be  recovered. 

NPS  email  can  be  obtained  by  linking  to  https://itw'arrior.nps.navv.mil/exchange/logon.asp 

OTA  bill  can  be  found  at  http://thomas.loc.gOv/cgti-bin/querv/z7c/07:HR2148 

19  Jun  2001 

JMO-T  ACTD.  Joint  Medical  Operations-Telemedicine,  Advanced  Concept  Technology 
Demonstration.  Went  to  Camp  Pendleton  ,  ELB  at  MCTSSA,  Marine  Corps  Tactical  Support  Systems 
Activity.  Met  Alfred  Mitchell,  Nick  North  and  Roger  Lisk  from  SAIC.  These  contractors  comprise  the 
Theater  Telemedicine  Team  (TTT)  whose  job  it  is  to  provide  support  for  the  JMO-T  technologies.  The  HF 
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data  communication  terminal  is  used  to  communicate  among  medical  units  and  is  fully  compatible  with 
SAMS  8.01,  Shipboard  Automated  Medical  System.  The  system  is  planned  to  be  fully  compatible  with  the 
future  Joint  Theater  Medical  Information  Procedure  (JTMIP).  Also  met  with  Army  SGT  Hall  and  PFC 
Ruff  who  will  be  using  the  system  during  FBE-I. 

The  unit  is  run  off  of  a  laptop  and  is  contained  in  a  protective  box,  approximately  3’x3’x  4’  and 
contains  the  MINC,  microintemet  controller  (JINC  =  Joint  internet  controller)  which  is  the  hardware  unit 
that  allows  connection  to  the  HF  (2-40  MHz)  unit.  The  system  has  a  global  UPS,  universal  power  source 
which  converts  almost  all  available  electrical  power  sources  to  1 10  V,  60  Hz  AC.  Current  capability  is 
through  a  Harris  digital  unit  with  2400  bps.  Upgrade  expected  in  the  near  future  is  9600  bps.  Range  is  3.5 
to  a  50  miles,  limited  by  power  and  ionospheric  conditions. 

The  system  is  capable  of  sending  photographic  information,  as  well  as  digital  v^itten 
communication. 

The  laptop  may  be  used  for  3  hours  on  battery  and  indefinitely  through  the  power  source. 

Currently  the  communication  radios  for  San  Diego  City  is  900  MHz,  San  Diego  County  800  MHz 
and  the  Navy  uses  400  MHz.  The  MINC  allows  communication  between  these  otherwise  incompatible 
systems. 

A  feature  which  could  prove  attractive  in  the  future  is  voice  communication  capability.  This  has 
not  been  incorporated  because  of  lack  of  funding. 

We  first  went  to  ELB  and  were  a  given  a  short  demonstration.  The  Coronado-ELB  link  was 
initially  not  available.  (We  believe  this  was  because  the  Coronado  was  experiencing  communication 
difficulties.) 

We  next  went  to  the  1^  Marine  Expeditionary  Force  (IMEF)  medical  unit  Bravo  Company  where 
two  Navy  hospital  corpsmen  were  to  give  training  on  its  use  to  the  two  Army  medics.  If  tomorrow  the 
army  medics  are  able  to  use  the  system,  then  the  unit  is  relatively  user  friendly. 

The  Army  Medical  (AMED)  units  have  bought  200  of  these  HF  Data  Communication  Terminals. 

The  system  was  used  in  Cobra  Gold  2001  in  the  Kingdom  of  Thailand. 

20  Jun  2001 

While  waiting  for  the  exercise  to  begin,  we  saw  a  vehicle  prototyped  by  General  Dynamics  called 
Reconnaissance  Surveillance  Targeting  Vehicle  (RSTV).  This  is  a  HMMV  type  vehicle  which  has  a 
smaller  wheel  base  to  fit  inside  a  V-22  and  weighs  less  (6500  lbs.  vs  8000  lbs.),  so  that  it  can  be  flown  as 
payload.  The  GD  representative  is  Bill  Tucker,  a  1983  NFS  graduate  who  had  Hersh  Loomis  as  thesis 
advisor.  Email:  tuckerw@gdls.com.  The  project  manager  is  a  former  Marine  COL  Rick  Duvall,  email: 
duvall@gdls.com.  The  vehicle  is  constructed  from  commercially  available  parts  and  is  a  electromagnetic 
hybrid  vehicle. 

While  we  were  waiting  to  go  to  Red  Beach,  the  landing  site  for  AAV’s  (Amphibious  Assault 
Vehicles,  12  in  number)  and  two  LCAC’s  (Landing  Craft  Air  Cushion),  the  medic-corpsman  team 
attempted  to  enter  data.  Data  entry  was  impeded  because  the  EUT  (End  User  Terminal  =  laptop)  had  a 
difficult  cursor.  Introduction  of  a  mouse  helped  considerably  in  data  entry  and  control. 

The  initial  entry  took  about  20  minutes.  Some  of  that  was  due  to  unfamiliarity  with  the  data  base 
and  keyboard  and  program,  some  was  due  to  social  interactions  among  the  2  army  medics,  2  navy 
corpsmen  and  one  army  evaluator.  In  a  real  situation,  some  of  the  database  could  be  preloaded,  e.g. 
demographic  information.  According  to  one  of  the  corpsmen,  the  use  of  the  pull  down  menu  eliminated 
unacceptable  entries.  The  Army  evaluator  was  MSGT  Flint,  who  had  used  the  system  in  Thailand  during 
Cobra  Gold  where  the  communicating  units  were  land  based.  The  only  thing  different  in  this  situation  is 
that  the  receiving  unit  is  afloat,  the  USS  Coronado.  Navy  Corpsmen  were  HM2  Smith,  760-763-0850/ 

0701  and  HM2  Simpson,  760-725-8099/0112. 

The  beach  landing  was  quite  impressive  with  the  AAV’s  and  LCAC’s  coming  ashore  from  about 
three  miles. 

14:09  Received  permission  to  submit  report.  We  drove  to  a  wooded  remote  site  and  tried 
transmission.  The  EUT  being  about  120  feet  from  the  CV  (Communication  Van),  did  not  have  a  good 
connection.  When  the  EUT  was  moved  to  the  van,  connectivity  to  the  Coronado  was  missing.  We  had  a 
difficult  time  determining  where  the  link  was  broken.  A  useful  addition  might  be  an  automatic 
acknowledgement  of  receipt  of  signal,  not  necessarily  information,  from  the  CV  to  the  EUT;  from  the 
aircraft  to  the  EUT  and  then  from  the  ship  to  the  EUT.  Only  the  last  step  is  provided,  so  the  data 
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transmitter  does  not  know  where  the  link  is  broken  without  arduous  trial  and  error  and  guesswork. 
Communication  from  the  aircraft  revealed  that  the  broken  link  was  between  the  CV  and  the  aircraft.  It 
turned  out  the  antenna  amplifier  had  been  turned  off  in  the  CV.  In  between,  we  were  urged  to  move  to 
higher  ground,  a  move  that  was  not  necessary. 

14:42  First  report  containing  information  about  two  people  were  sent  out.  (This  was  done  by 
Fred  Mitchell,  the  SAIC  contractor. ) 

14:45  Acknowledgement  of  receipt  of  data  received.  Medics  and  corpsmen  took  over.  No 
transmission  was  made  because  the  EUT  battery  died. 

Question:  Why  isn’t  earlier  testing  done  outside  of  the  exercise  environment? 

Moved  to  another  location.  Disease  Non-Battle  Injury  (DNBI)  report  from  the  refugee  camp  was 
sent  while  in  route  and  at  new  site.  This  was  done  from  a  pre-created  data  file.  Most  data  sent  required 
about  2  to  4  seconds.  One  took  64  seconds.  (Protocol  to  decide  when  and  how  to  resubmit  when  no 
acknowledgement  is  received  is  needed.)  The  DNBI  was  sent  as  a  Team  Care  Automated  System  (TCAS) 
file  without  the  SAMS  software  in  the  EUT. 

Talking  to  the  corpsmen  and  medics,  one  reason  for  slow  battle  injury  data  transmission  is  that  the 
data  collectors  were  making  involved  diagnostic  calls  on  the  spot.  (Maybe  this  can  be  alleviated  with 
experience  or  a  protocol  requiring  quicker  judgement.)  There  was  only  one  hour  allocated  in  the  exercise 
for  the  data  transmission  and  in  reality  many  hours  were  needed.  Each  patient  entry  requires  about  10 
minutes  to  complete  the  multi-page  report. 

15:47  All  15  battle  injury  reports  were  received  and  acknowledged. 

In  the  army  context,  the  EUT  and  reporting  system  would  be  useful  at  a  battle  aid  station  (BAS), 
but  its  bulkiness  would  limit  its  usefulness.  If  the  system  could  be  put  into  a  palm  pilot,  jump  teams  could 
use  the  software. 

CV  was  developed  by  DRS  Inc.  David  Breazeale  was  the  engineer  for  the  £UT. 

21  Jun  2001 

Back  at  FCTCPAC.  FCTCPAC  is  not  directly  linked  with  the  ELB  Wamet,  there 
is  no  communication  with  the  medical  activities  in  the  field,  or  on  the  USS  Coronado. 
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Items  for  consideration:  The  data  entry  for  SAMS  8.01  is  quite  extensive.  The 
entries  are: 

SSN 

Name 

Encounter  start  time  and  date  (default  allowed) 

Visit  type  (e.g.  initial) 

Height  (inches) 

Weight  (lbs.) 

Date/time  vitals  taken  (default  allowed) 

Blood  Pressure  Diastolic 
Arm  (L  or  R) 

Position  (Supine) 

Temperature  (degrees  Fahrenheit) 

Taken  (oral,  rectal,  etc.) 

Pulse  Rate 

Rhythm  (regular/  irregular) 

Respiratory  Rate 
Chief  complaint 
Initial  (user’s  id) 

Subjective  (paragraph  for  subjective  description  or  diagnosis) 

Objective  (PE,  patient  evaluation,  according  to  injury) 

ICD9 

Primary  assessment 
ICD9 

Secondary  Assessment 

Plan  (plan  at  Battle  Aid  Station,  BAS) 

Disposition  (e.g.  medevac) 

For  use  by  jump  teams  or  when  time  is  critical,  the  user  should  have  the  option  to 
ignore  fields  except  those  they  deem  critical.  There  should  be  the  ability  later  on  to  fill  in 
the  other  fields  depending  on  field  activity  density.  Also,  in  an  ideal  situation,  certain 
fields  like  SSN  and  names  could  be  pre-entered  for  all  combatants  in  a  local  unit.  (e.g. 
platoon)  There  is  a  danger  of  having  too  much  data  preloaded  in  a  pull  down  menu 
because  each  entry  detracts  from  the  time  needed  for  the  encounter  and  data  entry.  As 
currently  designed,  the  data  entry  is  time  consuming  (HM2  Simpson’s  comment  was 
“tedious”)  and  in  a  triage  or  medevac  request  situation,  there  are  too  many  fields  to  enter. 
A  combination  of  training  and  data  entry  format  could  alleviate  this  problem. 

Tomorrow,  we  will  go  back  to  Camp  Pendleton  and  make  contact  with  the  1st  LT, 
who  is  the  J4.  CDR  Rod  Abbott  was  there  today  and  relayed  that  there  were  battle 
casualties  in  the  war  scenario.  The  war  scenario  battle  casualties  may  not  be  directly 
connected  with  JMO-T,  but  should  give  us  a  better  appreciation  of  how  casualty  reporting 
is  done  operationally  today. 

The  FBE-I  website  has  a  block  for  medical  communication  according  to  the 
network  centric  warfare  concept.  There  are  no  entries  under  medical.  Why  is  this? 
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22Jun2001 

We  spent  the  day  at  Camp  Pendleton  in  the  marine  tent/spaces  which  mimicked  the  US S 
Bonhomme  Richard,  which  was  removed  from  the  experiment  due  to  trouble  with  a  boiler.  We  met  CAPT 
Joon  Um,  J4. 

The  communication  van  is  marked  A  =  Army,  M  =  Marine,  U  =  UOC  =  Unified  Operating 
Command.  The  UOC  was  run  by  John  Johnson,  SPAWAR,  who  seemed  very  knowledgeable. 

Government  employees  tend  to  have  a  broader  and  less  restrictive  knowledge  of  the  equipment  than 
contractors.  The  UOC  is  capable  of  easily  handling  10-15  EUT’s  and  has  the  capability  to  monitor  where 
links  exist  or  are  broken.  This  information  should  be  made  available  to  the  EUT’s,  so  that  the  operator  of 
the  EUT  can  determine  where  the  communication  failure  exists.  The  UOC  CV  was  about  400  feet  from  the 
EUT  in  the  marine  spaces. 

Question:  Are  military  personnel  being  trained  on  the  CV?  I  saw  no  uniformed  personnel  in  the 
CV,  only  contractors  and  one  government  employee.  Knowledge  by  the  EUT  user  concerning  the  function 
and  capabilities  of  the  CV  helps  understand  the  system  and  is  useful  in  troubleshooting  communication 
problems. 

Yesterday,  I  found  out  that  the  Coronado  is  coming  back  to  North  Island  rather  than  the  sub  base 
because  Point  Loma  masks  communication  satellites  about  40  %  of  the  time. 

At  about  09: 10,  a  casualty  re-appeared  (from  an  exercise  the  previous  day)  on  the  situational 
awareness  map  of  El  Centro.  It  was  not  until  about  09:45  that  confirmation  was  made  that  this  had  been  an 
actual  heat  stroke  condition,  not  a  simulated  one.  EUT  user  needs  to  be  trained  to  provide  written 
communication  as  email  when  using  the  JMO-T  system.  The  confirmation  was  made  by  a  PC2  satellite 
relayed  voice  message.  This  situation  also  illustrates  the  utility  of  incorporating  voice  capability  to  the 
ELB  WARNET. 

There  was  still  confusion  as  to  whether  the  heat  stroke  event  was  new  or  yesterday’s  event.  Voice 
communication  to  clarify  the  situation  as  yesterday’s  event  was  finally  made  at  about  09:58,  some  50 
minutes  after  first  noticing  the  event  marker  on  the  situation  map.  The  event  marker  (a  red  cross)  on  the 
situational  awareness  map  should  have  available  date/time  stamp  of  the  message,  so  the  on-scene 
commander  can  tell  when  the  event  occurred. 

Observing  the  activity  within  the  marines’  space,  in  this  situation,  the  marine  LCOL  functioned  in 
a  staff  capacity  to  the  Coronado.  It  was  not  clear  who  was  in  charge  of  the  observations  of  the  situational 
awareness  graphic  display.  The  red  cross  remained  with  no  indication  as  to  whether  action  had  been  taken 
or  even  whether  it  had  been  observed  by  a  person  with  an  active  role  in  the  exercise. 

25  Jun  2001 

LCDR  Baylor  returned  to  Camp  Pendelton  and  was  able  to  copy  both  the  casevac 
communications,  and  the  Combat  Services  Support  Request  (CSSR)  communications  from  the  El  Centro 
drills  last  week  as  text  reports  that  can  be  used  to  compare  timing  of  a  request  and  response,  should  this 
information  be  useful. 

I  came  on  board  the  USS  Coronado. 

Kathleen  Ward,  CNA,  had  to  leave  for  family  reasons. 

There  was  a  conference  with  PACOM  concerning  last  week’s  activities.  During  the  discussion,  the 
ability  to  see  the  same  visual  display  was  very  useful.  However,  the  discussion  was  done  with  verbal 
communication,  not  email.  The  importance  of  voice  communication  was  seen  here  also,  since  immediate 
response  allowed  for  a  meaningful  discussion. 

One  of  the  questions  brought  up  in  the  conferencing  with  PACOM  was  why  it  took  so  long  (15  - 
20  minutes)  to  enter  data  for  each  incidence/patient.  My  observations: 

a)  The  data  base  should  be  constructed  for  minimal  input  filling  in  other  fields  later  when  time  is 
not  a  factor.  When  the  personal  hand  held  communicator  is  used  (JEDI?),  there  should  be  an 
option  where  pad  button  input  should  be  allowed  for  certain  action  requests  such  as  medevac. 

b)  Part  of  the  time  is  social.  There  too  many  people,  2  medics,  2  corpsmen,  several  contractors 
and  others  looking  over  the  corpsman’s  shoulder  while  data  is  being  placed  into  the  system. 

c)  The  corpsman  felt  that  he  had  to  make  diagnosis  as  he  entered  the  data.  There  are  fields 
which  ask  for  subjective  evaluations.  Therefore,  an  evaluation  can  take  time  for  a 
conscientious  medic/corpsman.  The  construction  of  the  minimal  data  input  needs 
considerable  thought. 
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The  PACOM  RADM  made  an  observation  that  “without  data  input,  there 
is  no  system.”  There  are  events  which  do  not  show  up  unless  routine  input  is  made. 
Routine  data  collection  protocol  needs  to  be  defined  so  that  emerging  disease  trends  and 
epidemics  can  be  seen. 

DNBI  and  Battle  Injury  (BI)  data  should  be  incorporated  into  a  map.  Such  a  map  with  useful  color 
coding  would  allow  for  detection  of  epidemics  and  biological  attacks. 

Camera  image  is  useful  In  a  real  case,  a  seaman  onboard  the  USS  Bunker  Hill  had  an  eye  injury 
and  a  diagnosis  for  medevac  was  made.  Exchange  of  images  as  normal  email  attachment  enabled  the  3^^ 
Fleet  Surgeon  to  properly  make  the  diagnosis  that  the  injury  was  such  that  medevac  was  not  needed.  Had 
medevac  been  made,  then  there  would  have  been  an  unnecesary  impact  on  other  operations. 

(The  USS  Lake  Champlain  had  a  case  of  appendicitis  which  had  to  be  medevaced.) 

Identification  signs  on  various  EUTs,  pc’s: 

MeWS:  Medical  Workstation 
Watchboard 

-Collaborative  Planning  and  Reachback  Support 

-Annex  Q  Operational  Area  Reporting  (medical  logistics  info,  #  beds,  etc. ...) 
-Patient  Visibility 

Database  Server 

-Input:  SAMS  Patient  Data 

-Storage 

-Transfer 

-Communications 

MDSS:  Medical  Decision  Support  System 
Disease  Trend  Analysis 
Outliers  /  Bursts 
Summary  Reports 

Met  LCDR  Tom  Moskowitz,  on  the  staff  for  PA  CAM  Medical  Admin  at  Ft.  Smith,  Hawaii.  Maj. 
Dean  Doering,  USAF,  will  be  Tom’s  replacement. 

Weekly  Aggregate  DNBI  data  would  be  useful  for  humanitarian  relief,  refugee  camps.  This 
relates  to  earlier  comment  about  routine  data  entry.  Right  now  we  have  ‘‘new  visits”  and  “revisit” 
categories,  but  also  need  categories  of  “combat  related”  and  “not  combat  related”  as  well  as  “admin 
categories”  (e.g,  physicals). 

TCAS:  Team  Care  Automation  System  (data  input  for  all  medical  systems). 

TCAS  contains  messages.  Currently,  only  the  new  immediate  message  is  the  message  traffic 
stream.  Incoming  messages  and  outgoing  messages  are  in  different  files.  The  capability  to  intersperse  the 
outgoing  and  incoming  message  may  be  useful  to  follow  discussion  streams.  This  should  be  done 
according  to  message  time  sent,  for  example  . . .  Outgoing:  “What’s  the  temperature  there?”  Incoming: 
“101”.  Without  the  temporal  connection  between  these  two  message,  the  outgoing  file  only  shows  “What’s 
the  temperature  there”  without  connection  to  the  response.  Sometimes  the  messaging  connections  are 
severed,  so  the  operator  may  not  be  able  to  determine  what  is  going  on  when  there  is  only  the  message 
“101”,  without  reference  to  the  original  query.  Currently,  TCAS  returns  to  top  of  list  if  a  message  is  opened 
up.  Technical  fix  is  to  return  to  the  point  of  departure  when  a  message  is  opened. 

Procedure:  Most  operators  do  not  fill  in  the  subject  heading.  Putting  in  a  brief  subject  heading 
would  allow  for  better,  more  efficient  communication.  In  addition,  most  experienced  operators  initial  or 
sign  the  messages  so  that  the  receiver  knows  from  whom  the  message  is  coming.  Since  EUTs  in  the  field 
are  not  user  specific,  signatures  are  useful  in  maintaining  communication  streams. 

Spent  time  with  LCDR  Michelle  Hancock  concerning  the  websites  for  FBE-I.  There  is  a  IMEF/ 
JTF  website  which  is  supposed  to  contain  all  exercise-related  message  traffic.  The  JMO-T  message  traffic 
appears  to  be  on  this  system.  However,  there  is  a  parallel  NWDC  FBE-India  website  for  the  JTF.  It  has 
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space  for  Medical,  but  it  is  empty.  There  is  full  traffic  for  Joint  Fire,  Counterforce.  This  system  seems  to 
be  sued  at  FCTCPAC  and  UAV  traffic  is  on  the  discussion. 

Contacts:  Charles  D.  Updegrove,  MTS  Tech,,  301-319-1 179 

CDR  Scott  Sherman,  MD,  MPH,  Epidemiologist,  619-556-7070.  Scott  is  an  epidemiologist  who 
was  in  the  medical  spaces  on  the  Coronado  during  FBE-I. 

LCDR  Baylor  observed  a  late  afternoon  presentation  onboard  the  USS  Coronado.  It  concerned 
JMO-T  capabilities,  and  was  given  by  Fleet  Surgeon  CAPT  Jeff  Young,  and  CDR  Scott  Sherman,  to 
members  of  the  press/media. 

26  Jun  2001 

USS  Coronado  was  in  a  state  of  good  behavior  because  Prince  Andrew  was  coming  over  on  the 
Admiral’s  barge  across  San  Diego  Harbor  from  the  convention  center  where  there  is  a  big  biotechnology 
conference.  The  barge  was  accompanied  by  two  San  Diego  police  boats  full  of  a  crew  of  about  ten 
policemen. 

Teleconference  with  PACOM  surgeon  general,  who  is  also  the  CINCPAC  surgeon  general, 
RADM  Dennis  Wright,  J07. 

IMACS  =  situational  awareness  maps. 

Visit  by  CAPT  Dean  Bailey,  AirPAC  surgeon. 

A  point  brought  up  in  several  discussions  is  whether  all  of  new  equipment  reduces  the  up-front 
presence  of  personnel.  There  is  general  consensus  that  serious  analysis  should  be  a  rear  echelon  function. 
In  JMO-T,  the  current  concept  is  to  have  a  “help  desk  team”  with  two  contractor  technologists  riding  with 
the  ship.  This  would  increase  the  number  of  bodies  in  the  medical  spaces  on  board  the  ship. 

It  appears  that  there  are  at  least  three  reporting  systems  in  play  during  this  experiment.  There  is 
the  NWDC  FBE-I  webpage  which  is  monitored  by  those  in  the  JOC  for  airpower  support.  The 
experimental  side  of  the  medical  is  contained  in  the  IMEF/KBX  web  page  and  then  there  is  the  normal 
system  used  when  not  in  FBE  or  KBX.  The  heat  stroke  case  reported  last  week  should  have  been  using  the 
normal  operational  system,  but  was  placed  into  ELB  experimental  system. 

Conference  with  Dan  Gower,  gowerd@vrinet.com,  senior  analyst  for  Vector  Research,  Inc. 
accompanied  by  Stephen  Randolph,  Randolphs@vrinet.com.  policy  analyst.  Vector  is  tasked  to  do  testing 
and  evaluation  for  the  JMO-T  system.  Earlier,  Mike  Eby  and  Dennis  McCartin  had  approached  Vector 
about  collaborating  with  NSWC  about  testing  and  evaluation,  but  the  effort  did  not  get  anywhere  (probably 
because  NSWC  did  not  offer  to  pay  for  their  participation.)  They  had  a  questionnaire  which  gets  user 
reactions  to  JMO-T.  We  sat  around  a  table  with  SAIC  technicians  (Cynthia  Kramer  and  John  Wolthuis), 
fleet  surgeon  (CAPT  Jeff  Young),  epidemiologist  (CDR  Scott  Sherman),  two  medical  corps  personnel 
(LCDR  Michelle  Hancock,  deputy  fleet  surgeon,  and  CDR  Dennis  McCartin).  In  addition,  LCDR  Krissa 
Baylor,  Tom  Moskowitz,  PACOM  MSC  ,  Dean  D  *,  USAF  MSC,  Charles  Updegrove,  MTS,  and  I  were 
also  in  attendance. 

The  purpose  of  the  Vector  interviews  is  the  answer  the  following  two  questions: 

1 .  How  well  did  the  system  work? 

2.  How  well  it  help  the  mission?  (potential) 

The  questionnaire  will  be  graded  on  a  5  point  Likert  (linear):  Strongly 
Agree  =1,  Agree  =  2,  Neither  Agree  nor  Disagree  =  3,  Disagree  =  4,  Strongly  Disagree  = 
5,  Not  observed  =  (0).  This  scale  does  not  normalize  the  individual  respondent’s 
tendency  to  respond  high  or  low. 

Some  comments  heard  at  the  interview. 
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1 .  There  is  no  ability  to  input  aggregate  data.  For  functions  such  as  refugee 
camp  monitoring,  what  is  needed  for  command  response  is  aggregate  daily  or 
weekly  input. 

2.  To  the  question  as  to  whether  the  Watchboard/MDSS  software  is  compatible 
with  the  command  and  control  C2  system  (CINC21?),  the  answer  seems  to  be 
potentially,  but  not  in  its  present  configuation.  For  example.  Joining  Report  = 
Initial  Capability  Report,  could  be  accommodated  with  a  simple  change  of 
page  heading. 

3.  SAMS  is  not  designed  for  wartime  casualty.  It  is  more  for  hospital 
administration.  Provisions  should  be  made  to  redesign  SAMS  to 
accommodate  encounter  modules. 

4.  There  is  too  much  compartmentalization  in  software  and  elsewhere.  For 
example,  the  designers  of  Watchboard  have  one  clientele  in  mind,  but  there 
are  other  users.  Contractors  tend  to  work  only  on  the  scope  of  the  contract. 
Some  independent  assessment  is  needed  to  identify  changes  which  would 
accommodate  the  universe  of  users. 

5.  The  search  field  is  limited.  More  consideration  should  be  given  to  possible 
uses  for  the  search  and  find  out  if  there  is  enough  information  available  to 
make  a  useful  search.  For  example,  in  a  coalition  situation  or  a  large  refugee 
camp  situation  involving  Chinese  or  Korean  populations,  would  an  individual 
be  located.  (There  are  only  about  800  last  names  in  these  populations) 

6.  Would  an  alias  naming  system  be  useful?  (e.g.  Tarawa  1,  Tarawa2  indicating 
the  sequential  events  and  entries  from  the  Tarawa).  Any  alias  would  have  to 
be  noncritical  field  which  would  be  for  the  benefit  of  the  Fleet  Surgeon  for  his 
purposes. 

7.  The  ability  to  aggregate  data  fields,  e.g.  blood  types,  type  of  injury,  location, 
etc,  would  be  useful  for  the  Fleet  Surgeon  to  assess  situations.  This  relates 
back  to  an  earlier  observation  that  MDSS  should  be  able  to  back  track  to  the 
raw  data  and  allow  plotting  in  different  ways. 

8.  A  good  user  manual  is  needed.  The  user  manual  should  go  beyond  the 
cookbook,  step  1,  step  2  approach,  but  should  contain  discussion  of  the  topics 
and  philosophy.  This  might  be  a  textbook  type  manual. 

9.  Database  should  be  compatible  with  all  services  databases. 


We  tried  to  obtain  copies  of  the  MDSS/MeWS  filled  out  questionnaires, 
but  were  told  by  Vector  people  that  we  could  only  receive  processed  data. 

I  opened  the  two  files  LCDR  Baylor  saved  as  text  files  from  the  exercise  at  Camp  Pendleton  last 
week.  Casevac  stands  for  cases  potentially  requiring  evacuation  during  the  exercise.  It  is  a  fictional  entry 
into  SAMS. 

Example  is  given  below: 

Source :  RSTATMIBVTRSTATMI 
Call  Sign:  STALKERl 
Freq:  -0.0010  Hz 
Priority:  URGENT 
Required  on:  191601Z  JUN  01 
Pickup  site:  11SMS6040983976 
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Site  markings:  Pyrotechnic  Signal 

Pickup  type:  Air 

POC:  SGT  MAY 

Number  of  casualties:  1 

Nationality:  USMIL 

Security:  ENEMY 

Narrative :  RSTATMl — 

YOO  HOO  564948554  B+ 

FELL  BACKWARDS  DOWN  A  NEAR  VERTICAL  SLOPE... OPEN  WOUND  ON  THE  LEFT  SIDE 
OF  HEAD _ HAS  A  METAL  STAKE  THROUGH  RIGHT  THIGH . 


Combat  Support  Services  Request  (CSSR)  pertains  to  messages  for  equipment  support.  Examples 
are  given  below: 

Subject:  CSSR 

Date:  22  Jun  2001  09:26:46  -0700 
From:  SHNM 

Organization:  Shared  Net 
Newsgroups:  cssr,cssr 
Message  Type: CSSR 
services  : 
principleEndItem  : 

message .  supplyInfo[  0]  .unitOfIssue  :  EA_UOI 
message . supplyInfo[  0]  . quantityUnitPack  :  0 
message .  supplyInfo[  0]  .quantityOnHand  :  0 
message . supplyInfo[  0]  . quantityExpended  :  0 
message . supplyInfo[  0]  . quantityAuthorized  :  0 
message . supplyInfo[  0]  , consumptionRate  :  0.0 
message . supplyInfo[  0]  . quantityRequired  :  0 
message . supplyInfo[  0]  . quantityAvailable  :  0 
message  .  supplyInfo[  0]  .NSN  : 

message . supplyInfo[  0]  .SAC  :  Unknown  Supply  Account  Code 

message . supplyInfo[  0]  .supplyClass  :  Unknown  supply  class 

message  .  supplyInfo[  0]  .  quantityGreen  :  0 

message  .  supplyInfo[  0]  .  quantityYellow  :  0 

message  .  supplyInfo[  0]  .partNumber  : 

message  .  supplyInfo[  0]  .description  : 

enditem  : 

requestPriority  :  IMMEDIATE 
requiredOn  :  993226699 

instructions  :  NEED  1300  5.56  BALL,  5000  5,56  LINKED,  10000  7.62,  5000 
9  MM, 

pointOfContact  :  CO  GYSGT 
requestStatus  :  Unsent 

request Location . Latitude :  32.8154984431494 
request Location . Longitude :  -115.663736984929 
requestLocation .Altitude :  0.0 
requestLocation .MGRS :  11SPS2509231624 
serviceUnit  : 
narr  : 

acknowledged  :  false 
userid  : 

loginName  :  LC05MC0 
messageld  :  Unknown 
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inessageNuitiber  : 
dateTime  :  0 

observerLocation . Latitude :  0.0 
observerLocation . Longitude :  0.0 
observerLocation .Altitude :  0.0 
observerLocation . MGRS : 
report ingTrack  ;  lco5mcoBVTLC05MC0 
inf ormationSource  : 

View  role  :  CTP 
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Subject:  CSSR 

Date:  21  Jun  2001  13:41:07  -0700 
From:  SHNM 

Organization:  Shared  Net 
Newsgroups:  cssr,cssr 
Message  Type: CSSR 
services  : 
principleEndItem  : 

message  .  supplyInfo[  0]  .unitOf  Issue  :  EA_UOI 
message .  supplyInfo[  0]  .  quantityUnitPack  :  0 
message .  supplyInfo[  0]  .  quantityOnHand  :  0 
message. supplyInfo[  0]  . quantityExpended  :  0 
message. supplyInfo[  0]  . quantityAuthorized  :  0 
message. supplyInfo[  0]  . consumptionRate  :  0.0 
message. supplylnfd  0]  . quantityRequired  :  0 
message. supplyInfo[  0]  . quantityAvailable  :  0 
message.  supplyInfo[  0]  .NSN  : 

message. supplyInfo[  0]  .SAC  :  Unknown  Supply  Account  Code 

message. supplyInfo[  0]  .supplyClass  :  Unknown  supply  class 

message  .  supplyInfo[  0]  .  quantityGreen  :  0 

message  .  supplyInfo[  0]  .  quantityYellow  :  0 

message  .  supplyInfo[  0]  .partNumber  : 

message. supplyInfo[  0]  .description  : 

enditem  : 

requestPriority  :  ROUTINE 
requiredOn  :  993155721 
instructions  :  chow  request 
pointOfContact  : 
requestStatus  :  Unsent 

requestLocation . Latitude :  33.3190146149518 
request  Location .  Longitude :  *-117,4737  92966972 
requestLocation. Altitude :  0.0 
requestLocation .MGRS :  11SMS55 9008  6754 
serviceUnit  : 
narr  :  35S3 — 

Move  to  this  coordinate.  Fill  the  chow  request.  Acknowledge  you  have 

received  this  request  and  on  delivery  of  chow. 

acknowledged  :  false 

userid  :  35S3 

loginName  :  35S3 

messageld  :  Unknown 

messageNumber  : 

dateTime  :  0 

observerLocation . Latitude :  0.0 
observerLocation . Longitude :  0.0 
observerLocation .Altitude :  0.0 
observerLocation . MGRS : 
reportingTrack  :  35S3BVT35S3 
informationSource  : 

View  role  :  CTP 
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Subject:  CSSR 

Date:  21  Jun  2001  13:04:55  -0700 
From:  SHNM 

Organization:  Shared  Net 
Newsgroups:  cssr,cssr 
Message  Type: CSSR 
services  : 
principleEndItem  : 

message  .  supplyInfo[  0]  .unitOf  Issue  :  EA_UOI 
message . supplyInfo[  0]  . quantityUnitPack  :  0 
message  .  supplyInfo[  0]  .  quantityOnHand  :  0 
message . supplyInfo[  0]  . quantityExpended  :  0 
message . supplyInfo[  0]  . quantityAuthorized  :  0 
message . supplyInfo[  0]  . consumptionRate  :  0.0 
message . supplyInfo[  0]  . quantityRequired  :  0 
message. supplyInfo[  0]  . quantityAvailable  :  0 
message  .  supplyInfo[  0]  .NSN  : 

message . supplyInfo[  0]  .SAC  :  Unknown  Supply  Account  Code 

message. supplyInfo[  0]  .supplyClass  :  Unknown  supply  class 

message . supplyInfo[  0]  . quantityGreen  :  0 

message .  supplyInfo[  0]  .  quantityYellow  :  0 

message  .  supplyInfo[  0]  .partNumber  : 

message . supplyInfo[  0]  .description  : 

enditem  : 

requestPriority  :  ROUTINE 
requiredOn  :  993153648 
instructions  :  chow 
pointOfContact  : 
requestStatus  :  Unsent 

request Location . Latitude :  33.3058109707742 
request Location . Longitude :  -117.441592538184 
requestLocation .Altitude :  0.0 
requestLocation .MGRS :  11SMS5889185277 
serviceUnit  : 
narr  :  35S3 — 

Respond  to  this  request.  Physically  move  to  this  location.  LT  C 

acknowledged  :  false 

userid  :  35S3 

loginName  :  35S3 

messageld  :  Unknown 

messageNumber  : 

dateTime  :  0 

observerLocation. Latitude :  0.0 
observerLocat ion . Longitude :  0.0 
observerLocation .Altitude :  0.0 
observerLocation . MGRS : 
reportingTrack  :  35S3BVT35S3 
informationSource  : 

View_role  :  CTP 

In  a  real  situation,  ie.  request  for  chow,  water  or  medical  use  the 
word 

"Cherry"  to  begin  your  request  followed  by  "picker".  This  is 

universal 

any  real  request. 

(Note  that  this  message  says  “cherry  picker”  is  a  real  request.  Conversations  in  the  Marine  tent  lead  us  to 
believe  that  “cherry  picked’  were  simulated  events.  The  vocabulary  is  unique  to  this  unit  and  needs  to  be 


standardized.  Simulations  and  real  requests  need  to  be  differentiated.  The  Kemal  Blitz  documentation  says 
that  “cherry  picker”  is  simulated.) 

Met  former  student  Jon  Wood,  executive  officer  of  EOD  Mobile  Unit  3.  We  went  to  see  the 
dolphin  pens  on  Point  Loma  Submarine  Base.  It  appears  that  the  Navy  does  not  put  a  lot  of  resources  into 
the  operational  navy.  The  buildings  go  back  to  World  War  II  and  have  had  been  knocked  off  their 
foundation  and  re-propped  up. 

27  Jun  2001 

Back  to  USS  Coronado.  Discussion  with  Cynthia  Kramer.  After  pressing  her  on  certain 
capabilities  and  issues  regarding  the  JMO-T  software,  I  found  out  certain  elements  of  the  program  that  I 
had  not  fully  appreciated  before.  JMO-T  is  a  Commercial  Off-The-Shelf,  COTS,  program  which  explains 
why  the  data  bases  among  certain  parts  are  not  fully  compatible.  From  what  I  gather,  the  main  contribution 
of  the  contractors  is  to  provide  translation  software  so  that  field  units  can  send  data  to  populate  datafields  of 
more  sophisticated  higher  echelon  commands.  In  effect,  the  end  user  sends  data  which  is  cached  by  an 
echelon  2  command  which  may  use  it  within  itself.  In  analogy,  the  end  user  is  like  an  ambulance,  which 
forwards  information  to  a  hospital.  Internally  within  the  hospital,  the  different  units,  e.g.  admissions,  bed 
supplies,  test  lab,  etc.,  have  two  way  pipes  to  receive  data  and  send  data  to  the  central  repository.  The 
echelon  1  unit  effectively  has  only  the  ability  to  send  the  data,  but  not  to  receive  or  query  from  the  central 
repository. 

After  considerable  discussion  with  Cynthia  and  later  with  Cdr.  Sherman,  they  do  not  believe  two 
way  data  sending  ability  is  necessary  nor  desirable.  First,  the  lower  echelon  units  are  too  busy  in  the  heat 
of  battle  to  deal  with  incoming  data  and  second,  the  communication  is  usually  by  HF  so  there  is  insufficient 
bandwidth  to  transmit  data.  The  data  size  transmitted  by  the  EUT  is  1  kilobyte.  (This  limitation  seems  to 
say  to  me  that  voice  communication  is  more  essential.) 

Asking  Cdr.  Sherman  if  the  MDSS  was  useful  as  scripted,  he  was  of  the  opinion  that  the  scenario 
for  this  exercise  was  not  realistic.  The  military  would  not  get  so  intimately  involved  with  refugees  as  to 
require  data  on  an  individual  basis.  The  only  data  that  would  be  useful  would  be  aggregate  data.  (If  the 
MDSS  software  is  marketed  to  the  NGO  and  Humanitarian  aid  community,  its  search  capability  limitation 
must  be  clearly  put  forth.)  If  it  is  not  to  be  used  with  a  large  population  such  as  in  a  refugee  population,  I 
have  a  problem  with  the  change  detection  indicators.  In  most  military  situations,  the  case  numbers  will  be 
relatively  small,  so  making  change  indicators  based  on  one  to  three  standard  deviations  may  not  be 
meaningful  if  we  are  tracking  individual  events.  The  scenario  scripted  did  not  address  the  military  utility 
of  the  MDSS  program. 

Further  discussions  with  Mike  Sovereign  and  R.  Kemper  from  NFS  revealed  the  following.  The 
Marine  Corps  has  never  felt  that  they  would  have  sufficient  satellite  bandwidth.  Consequently,  they  are 
pushing  ELB  WARNET.  The  Navy  fires  exercise  are  carried  out  by  SIPRNET.  CINC21  is  a 
communication  network  which  includes,  uses,  or  is  part  of  SIPRNET,  but  at  this  point  is  quite  immature. 
NIPRNET  and  SIPRNET  uses  commercial  satellites  and  commercial  internet  links.  The  driving  force  is  to 
go  commercial  and  have  very  few  things  which  are  exclusively  military.  I  don’t  think  much  thought  has 
been  put  into  the  philosophical  question  as  to  what  is  the  military.  By  function,  civilian  contractors  must 
now  be  considered  military?  There  are  several  other  communication  links.  Hardly  anyone  has  an  overall 
view  of  the  link  situation. 

Generally,  contractors  are  very  constrained  in  that  if  it  is  not  something  they  are  being  paid  for, 
they  do  not  deal  with  it.  The  issue  of  how  to  deal  with  concerns  and  items  not  specified  in  the  contract 
needs  to  be  addressed  in  using  systems  such  as  JMO-T 

In  addition  several  billion  dollars  are  being  used  to  impose  the  Navy/  Marine  Corps  intranet  under 
a  contract  to  the  Dallas  Company  started  by  Ross  Perot  (E???),  Under  this  concept,  all  the  local  area 
networks  and  machines  which  are  locally  controlled  will  be  managed  by  one  Navy  Command.  Apparently 
there  is  now  talk  of  a  three  star  billet  for  Navy  IT.  (this  comes  from  the  Third  Fleet  deputy  PAO). 

28  Jun  2001 

Went  to  FCTCPAC.  Most  activity  shut  down. 

Used  the  San  Diego  Trolley  system.  During  the  middle  of  the  day,  it  is  pretty  full.  My  guess  is 
that  every  15  minutes  a  five  car  train  with  capacity  of  about  50  per  car  runs.  It  looks  like  it  is  used 
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extensively  by  commuters  from  Tijuana  and  by  attendants  at  the  baseball  games.  There  are  two  lines,  the 
Blue  Line  runs  between  the  San  Diego  Mission  and  Tijuana  and  the  Orange  Line  starts  downtown  and  goes 
out  southeast. 

29  Jun  2001 

Hotwash,  Kemal  Blitx  (X). 

The  wrap-up  meeting  of  KB(X)  and  FBE-I  was  held  at  the  Amphibious  Training  Base  theater. 

The  format  was  to  present  each  topic  with  3  positive  and  3  negative  bullets  with  discussion  interspersed. 
(My  comments  will  be  in  parenthesis.) 

General: 

+  Naval  Fires  Network: 

+  Ku  Band  Satellite  Network 

+  10  Network  Defense  Network, (hacking  text  tested  and  seems  to  work.) 

-  Unclassified  network  on  ECOC  (WARNET  does  not  conform  to  classified  standards.  It 
conforms  to  COTS  128  bit  encryption,  but  that  is  not  good  enough  for  national  security.) 

Split  IP  GBS  (not  testedO 

JCSE  (=  Joint  Continuous  Strike  Exercise,  work  other  systems  to  make  work,  it  is  a 
comparison  program.  It  was  not  tested.) 

JFMC: 

+  Control  of  Fires  (who  votes?) 

+  RTC/TES-N  is  potential  ISR  force  multiplier 
+  Littoral  Pnetration  Area  (complicated  layers) 

-  Targeter  and  Weaponeer  pair  (they  should  be  in  the  same  space) 

LAWS  Operator  experience 

Execution  and  planning  tools  (need  to  develop) 

JFACC 

+  greatly  increased  spread 
+  improved  joint  collaboration 
+  improved  situational  awareness 

-  paucity  and  reliability  of  live  ISR  assets  (UAV,  satellites?) 

-  low  density  and  fidelity  of  ISR  injects  into  exercise 

fragile  interfaces  between  systems  and  equipment 
(only  had  5  U2’s  and  2  JSTARS;  NFN  needs  simulated  access) 

MARFOR/MCWL 

Timeliness  of  mensuration  of  tactical  targets  (took  40  minutes) 

Simulation  package 

Limitation  of  Radiant  Mercury  System  Interface 
+  Enhanced  common  tactical  picture/  battlespace  awareness 
+  Improved  IMMACCS/  WARNET  System  Stability 
(unclassified  side  showed  no  air  assets,  must  have  classified  interface) 


System 

Works  ? 

Tactical  Value 

WARNET 

yes 

high 

BVT(CTP) 

yes 

H*  Low  (H*  with  classified  access,  low  without) 

CHAT 

yes 

high 

NEWSGROUPS 

yes 

low 

IVOX 

Intermittent 

Unknown 

EUT 

yes 

medium 

CUSEEME/whiteboard 

barely 

low 

LAWS 

yes 

medium 
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JSOTF  (Joint  Special  Operations  Tactical  Force) 

Notional  play  -  planning  and  execution  (no) 

Collaboation  tools  and  connectivity  (no) 

LAWS,  GCCS,  GISR-N  (no) 

Information  management  (no)  (3  different  web  pages,  no  standard) 
Unattended  Ground  Sensors  and  Aerolight  UAV  (no) 

(aeroiight  UAV  is  not  useful  unless  it  is  man  portable) 


Intelligence: 

+  Collaborative  tools 
+  Web-based  posting  of  intelligence  briefs 
+  Intelligence  preparation  of  the  battlefield 

-  COP  dedicated  to  the  intelligence  sector  in  the  JOC  (overlay  needed) 

-  Training  prior  to  experiment 

Collection  Manager  vrs  ISR  manager 
(stopping  for  twice  daily  brief  is  disruptive) 

Command  and  Control: 

End  User  Terminal  (EUT) 

CHATROOMS 

WARNET 

IMMACCS 

PLI 

Joint  Fires: 

+  Integration  of  system 
+  Rapid  Sharing  of  Information 
+  Decentralization  of  Execution 

-  Integration  of  Experiment 

-  Analysis  of  Combat  Information 

Enforcement  of  GICOT 

Communications : 

Navy/Marine  Corps  Cooperation 
Experimentation:  Team  Apps 
Com  Ex/ 


FBE-I: 

Wideband  network  centric  communication  to  all  notes 

TTP  development  and  system  evaluation  with  USMC  (JTF  StafFcomponents) 

USW  integration  into  the  DFN  provided  chared  SA  and  enhanced  warfighting  capability 
Incomplete/  not  fully  planned  ISR  plan  degraded  the  TCT  process 
Nodal  mensuration  was  not  reliable 
Experiment  Complexity  demanded  longer  workups 

ELB: 

Successfully  shared  tacrtical  picture  between  LFCC,  ARFOR  and  fielded  forces 
WARNET  supported  NFN  LTC  and  JMO-T 

Demonstrated  WARNET  ability  to  interfere  with  standard  network  systems 

Net  management  needs  work 

Net  robustness  good  but  not  seemless 

Collaborative  planning  applications  and  IVOX  not  optimized  for  WARNET  use 

(a  200  know  airplane  was  used  rather  than  a  slow  moving  UAV  so  coverage  was  not  even) 
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CINC21 


Building  CINC’s  and  CJTF  daily  briefs 

Collaboration 

Visualization  tools 

Medical  Support 

Counterforce  experiment  support 

Training  and  Assessment 

XI S  real  time  incidence 

CTP  common  tactical  picture 

Medical  support-  entrepeneurial 

Whiteboard 

(05 ’s  and  06’s  need  training  perhaps  more  than  the  operators) 


JMO-T 

+  Replaces  traditional  msg/  radio  traffic 

+  Improves  centralized  management 

+  Provide  digital  two-way  comms  and  file  transfer  (Limited) 

-  End  user  data  entry  capability 

-  Database  search  capability  (needs  Boolean  algebra  capability) 

Medical  Watchboard  Format 

Trend  analysis 

Separate  DNBI/  Casualty  databases 
CINC21  collaborative  planning  was  helpful 

Data  entry-SAMS 

8000  entries  -reachback  capability  needed 
watchboard  format  -  COP  did  not  exists  (IMMACCS) 


KB  (X)  director: 

Wargame 

Contractor  support  for  paperwork  ,  e.g.  MSEL  list 

Uniforms  in  charge  -  continuity  of  program  leads  (who’s  in  charge) 

Net  accreditation  issues  ~  installs  (xpt  does  not  own  network) 

ISR  assets 

Berthing  availability 
ELB  --  CINC21 

PAO,  DV  media  events  held  on  weekend,  media  response  small 
Closing: 

The  order  of  priority  was  network,  sensors,  weapons  systems  and  platforms.  This  is  opposite 
order  of  previous  games. 

JTF  -  not  all  players  were  there 

No  robust  enemy  environment 

Have  commander  decide  what  he  wants  to  see 

Squad  leaders  depend  on  accuracy  of  COP  (Date/time  stamp  needed) 

DOTES  -  Doctrine,  Operations,  Training,  Education  System 

MC02  in  one  year. 
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Appendix  2 


10  August  2001 

FBE-I  Exercise  Report:  JMO-T  ACTD 


Kathleen  Ward 

Center  for  Naval  Analysis 


Executive  summary 

Fleet  Battle  Experiment  India  (FBE-I)  Far  Forward  Casualty  Care  Initiative  provided  the 
initial  opportunity  to  experiment  with  the  Joint  Medical  Operations-Telemedicine 
Advanced  Concept  Technology  Demonstration  (JMO-T  ACTD).  The  overall  goal  of  this 
technology  demonstration  was  to  provide  a  medically-oriented  decision  support  system  to 
the  Joint  Task  Force  Surgeon  (JTF  Surgeon).  The  ability  to  detect  potential  epidemics,  to 
predict  shortfalls  in  blood  and  medical  supplies,  or  to  follow  patient  and/or  staffing  levels 
at  various  JTF  treatment  facilities  are  all  crucial  to  maintaining  the  medical,  and  more 
importantly,  the  operational  capabilities  of  the  Joint  Task  Force. 

Experimentation  efforts  were  divided  between  two  core  technologies  that  make  up  JMO- 
T  ACTD:  the  Medical  Watchboard  (MeWS)  and  the  Medical  Decision  Support  System 
(MDSS).  The  experiment  patient  population  was  built  around  both  military  (Injured: 
-100,  DNBI:  -200)  and  civilian  patients  (DNBl:  -6000)  in  refugee  camps.  Military 
injury  patient  encounters  were  entered  via  the  Shipboard  Non-Tactical  ADP  Program 
(SNAP)  Automated  Medical  System  (SAMS)  patient  encounter  module.  Additional 
Disease  Non-Battle  Injury  (DNBI)  patient  encounter  files,  prepared  prior  to  the 
experiment  due  to  the  large  volume  of  patients,  were  simply  uploaded  into  the  MeWS 
database  for  subsequent  analysis.  CINC-21  collaborative  planning  tools  (multi-point  net 
meeting  with/without  video)  were  also  used  during  this  experiment,  but  were  not  the 
primary  focus  of  the  exercise. 

Biological  warfare  agents  are  inherently  difficult  to  detect.  It  is  likely  that  detection  of  an 
attack  will  only  occur  upon  initial  diagnosis  of  the  agent  in  the  military  population.  As  a 
result,  this  experiment  concentrated  primarily  on  MeWS  and  MDSS  epidemic  detection 
and  analysis  capabilities.  Also  examined  were  the  decisions  made  by  the  JTF  Surgeon 
and  staff*  and  subsequent  medical  coordination  efforts  with  Commander-in-Chief,  Pacific 
(CINCPAC)  Surgeon  and  staff. 

Final  results  from  this  exercise  indicate  that  JMO-T  ACTD  can  alert  on  an  emerging 
epidemic.  Because  this  alert  is  not  automated,  actual  detection  of  an  alert  requires 
additional  time  and  effort  by  JTF  personnel.  The  technology  does  not,  however,  provide 


'  Similar  analyses  using  another  epidemiologic  software  package,  Global  Epidetionary  Medical  System 
(GEMS- A),  was  carried  out  August  2000  during  FBE-H.  Ward,  KM  and  McGrady,  ED.  MCOO/FBE-H 
Biological  Warfare  Limited  Objective  Experiment  (U).  CNA  Research  Memorandum  CRM  D0003627.A1, 
March  2001  (SECRET). 
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a  diagnostic  capability  to  the  JTF  Surgeon.  After  an  alert  in  the  military  population,  a 
manual  workaround  developed  by  the  JTF  surgeon  provided  a  diagnosis,  after  analysis  of 
24  patients  in  90  minutes.  Similar  analysis  using  this  manual  workaround  on  a  second 
exercise  alert  would  have  taken  over  2  weeks.  Instead,  an  alternative  software 
workaround  developed  during  the  exercise  enabled  diagnosis  after  analysis  of  6000 
refugee  patients  in  30  minutes. 

In  the  military  population,  both  analysis  tools  (MeWS,  MDSS)  alerted  the  JTF  Surgeon 
to  an  unusual  level  of  respiratory  illness  on  the  first  day  of  the  exercise.  These  unusual 
levels  continued  until  day  three  when  a  detailed  analysis  of  clinical  signs/symptoms 
revealed  the  possibility  of  a  bio-warfare  attack  against  the  Task  Force.  Following  earlier 
notification  of  the  JTF  Commander,  the  JTF  Surgeon,  using  the  CINC-21  reach-back 
capability,  was  able  to  discuss  these  findings  directly  with  CINCPAC  Surgeon.  This 
resulted  in  notional  tasking  of  rapid  laboratory  assets  to  the  Task  Force  in  order  to 
conduct  confirmatory  investigations  of  the  possible  bio-warfare  event.  The  CINCPAC 
Surgeon  also  concurred  with  JTF  Surgeon  actions  on  immediate  antibiotic  treatment  and 
prophylaxis  of  Task  Force  service  members. 

MDSS  alerted  on  the  initial  day  for  the  three  separate  epidemics  of  malaria, 
gastrointestinal  disease,  and  measles  in  the  refugee  camps.  These  alerts  were  based  on 
the  grouping  of  specific  ICD-9  codes  into  category  syndrome  groups  (respiratory,  GI, 
fever)^.  These  results  demonstrated  the  alert  capability  against  a  large  background  set  of 
sick  patient  information,  as  compared  with  the  previous  mentioned  alert  arising  from 
~300  military  patients. 

A  number  of  software  limitations,  however,  hampered  the  medical  and  operational 
effectiveness  of  the  JMOT-ACTD.  The  next  requirement  following  initial  detection  of  an 
unusual  medical  event  is  the  determination  of  the  cause(s).  A  working  diagnosis  can  be 
obtained  though  analysis  of  clinical  signs  and  symptoms  or  through  laboratory  testing  of 
tissue  and/or  blood  samples.  Because  laboratory  capabilities  are  severely  limited  at  sea, 
the  ability  to  analyze  clinical  signs  and  symptoms  is  absolutely  necessary  to  ensure  an 
appropriate  medical  response. 

MDSS  does  not  currently  offer  the  user  access  to  clinical  sign  and  symptom  information, 
though  it  is  contained  in  the  database.  During  FBE-I,  a  non-automated  “stubby  pencil” 
analysis  of  MeWS  and  MDSS  data  was  conducted  following  the  initial  detection  of  the 
military  epidemic.  This  enabled  the  JTF  Surgeon  to  determine  an  appropriate  differential 
diagnosis  (tularemia)  and  to  dictate  his  subsequent  medical  decisions.  This  type  of 
manual  analysis  is  viable  only  for  a  small  patient  population  (24  patients  in  this  exercise). 
The  significantly  larger  refugee  epidemic  (requiring  analysis  of  6000  patients)  could  not 
be  analyzed  using  MDSS  in  its  current  form. 


^  A  similar  strategy  for  biological  surveillance  is  suggested  by  Brinsfield,  KH,  et  al.  2001.  Using  Volume- 
based  Surveillance  for  an  Outbreak  Early  Warning  System.  Academic  Emergency  Medicine.  8(5)  492. 
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•  Recommendation:  Implement  the  software  workaround  (written  on-board  USS 

Coronado  during  FBE-I)  to  access  the  entire  MDSS  database  for  subsequent 
download  into  Excel  or  other  user-desired  spreadsheet  analysis  software  package. 

•  Recommendation:  Implement  Epidemiologic  Wizard  (EpiWIZ)  in  MDSS 
software  suite  for  use  by  medical  operators.  Future  experiments  should 
specifically  focus  here,  utilizing  either  real  or  simulated  patients,  to  enable 
operator  feedback  on  this  interim  epidemiologic  capability. 

•  Recommendation:  Develop  "key  word"  search  and  analysis  capability  for 

future  inclusion  into  MDSS.  It  must  also  include  the  ability  to  group  a  specific 
list  of  signs  and/or  symptoms  as  well  as  to  require  one  specific  sign  or  symptom. 
These  lists  could  be  saved  as  core  analysis  parameters  either  as  determined  by 
higher  authorities  or  as  written  by  the  deployed  end-user. 

Another  drawback  stemmed  from  current  manning  levels  on  the  JTF  Surgeon’s  staff. 
These  are  inadequate  to  exploit  the  totality  of  information  available  from  this  technology. 
For  example,  initial  detection  of  an  outbreak  using  MDSS  is  not  an  automatic  function  of 
the  software.  Instead,  it  depends  upon  user  review  of  each  specific  disease  category 
listed  for  all  JTF  operating  units,  both  individually  and  collectively.  Because  of  the  sheer 
volume  of  information,  this  review  alone  is  a  significant  task  for  a  single  individual. 
Additional  requirements  for  JMO-T  ACTD  medical  information  only  added  to  the 
workload  of  the  JTF  Deputy  Force  Surgeon  during  FBE-I.  These  included  inputs  to  JTF 
Commander’s  briefings,  website  updates,  database  downloads  to  CINCPAC,  and  daily 
interactions  with  CINCPAC. 

•  Recommendation:  Determination  of  appropriate  additional  JTF  Surgeon 

staffing  levels  (not  limited  to  on-board  personnel,  if  mirrored  website  MDSS 
access  is  available). 

•  Recommendation:  Determination  of  standardized  review  procedures  and 

requirements  to  ensure  complete  review  and  consistent  analysis  of  population 
database. 

•  Recommendation:  Future  JMO-T  ACTD  developmental  efforts  should  provide 
an  automated  presentation  of  the  initial  MDSS  detection  of  any/all  outbreaks  to 
the  user  upon  login,  rather  than  via  systematic  operator  review. 

A  final  drawback  arose  from  the  “sneaker-net”  workaround  required  by  CINC21  and 
JMO-T  ACTD  security  requirements.  As  a  result,  consistent  information  disconnects 
were  noted  during  FBE-I.  Optimal  use  of  JMO-T  ACTD  in  collaborative  planning  and 
response  to  medical  events  requires  rapid  and  secure  communications,  which  include 
both  voice  and  data  transmission  capabilities.  The  information  available  is  both  an 
OPSEC  vunerability  and  a  significant  privacy  issue,  since  this  technology  provides 
complete  access  to  individual  patient  medical  records.  Accordingly,  numerous  security 
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issues  remain  that  were  not  addressed  by  this  experiment  but  which  need  to  be  evaluated 
in  future  efforts. 

•  Recommendation:  Future  medical  experiments  should  ensure  that 

communications  are  rapid,  reliable,  and  secure  in  order  to  take  fullest  advantage 
of  the  collaborative  capabilities  of  new  technologies. 

JMO-T  ACTD  functions  that  were  successfully  demonstrated  during  FBE-I  included: 

•  Initial  alert  on  and  detection  of  epidemics:  All  four  exercise  epidemics  were 
detected  on  the  first  day  of  each  epidemic. 

•  Database  reliability:  The  MeWS  server  was  robust  and  dependable.  No 
problems  were  experienced  with  the  server  during  the  entire  exercise,  despite  the 
fact  that  it  was  operating  24  hours  a  day  on  laptop  computer  technology. 

•  Up-to-date  medical  status  of  forces:  The  MeWS  watchboard,  patient  tracking 
capabilities,  and  TCAS  e-mail  connectivity  worked  consistently  well  throughout 
the  exercise.  This  particular  exercise  scenario,  however,  was  not  designed  to 
specifically  exploit  these  functional  capabilities.  Future  experiments  could  focus 
on  these  particular  MeWS  capabilities,  utilizing  either  real  or  simulated  patients, 
to  better  demonstrate  these  the  value  of  these  functions  in  operational  situations. 

•  Collaborative  planning  and  communications:  The  combination  of  JMOT-ACTD 
with  CINC-21  communications  facilitated  the  rapid  and  coordinated  responses 
between  the  JTF  Surgeon/staff  and  CINCPAC  Surgeon/staff. 
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FBE-I  Exercise  Report 


Kathleen  Ward 

Center  for  Naval  Analyses 


Introduction 

FBE-I  Far  Forward  Casualty  Care  Initiative  was  designed  to  examine  the  utility  of 
medical  analysis  tools  (JMO-T  ACTD)  for  their  value  to  the  Force  Surgeon  and  to  the 
JTF  Commander.  JMO-T  ACTD  is  a  prototype  of  an  advanced  medical  information 
system  designed  to  enhance  force  health  protection  and  medical  decision  making 
capabilities.  This  system  was  evaluated  during  FBE-I  using  a  combined  military  and 
civilian  refugee  scenario,  with  the  primary  focus  on  the  detection  and  analysis 
capabilities  offered  by  JMO-T  ACTD  epidemiologic  alert  and  analysis  functions. 

Technologies  employed: 

Medical  Decision  Support  System  ('MDSS') 

MDSS  is  the  medical  event  detection  and  the  primary  epidemiologic  analysis  tool  of 
JMO-T  ACTD.  It  is  responsible  for  identifying  and  alerting  significant  medical  events  in 
patient  encounter  data.  Various  functions  in  MDSS  include: 

•  Disease  trend  analysis 

•  Means  and  standard  deviation  calculations 

•  Outliers  determined  (between  1-3  standard  deviations  away  from  mean) 

•  Bursts  determined  (greater  than  3  standard  deviations  away  from  mean) 

•  DNBI  category  groupings  (Based  on  ICD-9  codings) 

•  Individual  patient  file  review 

•  Summary  reports 

The  disease  trend  analysis  function  requires  either  background  historical  data  or  at  least 
the  previous  5  days  worth  of  patient  information.  This  experiment  provided  10  days  of 
background  patient  information  from  the  scenario  refugee  camps. 

Medical  Work  Station  (MeWS) 

MeWS  acts  as  the  central  database  for  incoming  patient  medical  encounter  files  and 
provides  database  snapshots  periodically  to  MDSS  for  subsequent  analysis.  It  also 
handles  information  relating  to  the  medical  status  of  the  MTF  using  standardized  Annex 
Q  reporting.  It  tracks: 

•  Medical  personnel  (manning  levels  vs  actual) 

•  Number  of  Injured  military  personnel 

•  Bed  status  per  medical  unit 
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Medical  supplies 
Blood  supply  status 
Patient  movement  tracking 


In  addition,  the  Team  Care  Automated  System  (TCAS)  function  of  MeWS  permits  on¬ 
line  direct  e-mail  connectivity  between  remote  medical  providers  and  the  JTF  Surgeon. 


Exercise  partnerships 


Other  partners  who  contributed  to  the  Far  Forward  Casualty  Care  Initiative  included: 


•  Extending  the  Littoral  Battlespace  (ELB)  ACTD 

•  CINC-21  ACTD 

•  Commander  in  Chief,  Pacific  (CINCPAC)  Surgeon 

•  Commander  Third  Fleet  (COMTHIRDFLT)  Surgeon 

•  I  Marine  Expeditionary  Force  (I  MEF)  Surgeon 

•  Navy  Environmental  Health  Protection  Unit  Five  (NEPMU  5) 

•  Navy  Health  Research  Center  (NHRC),  San  Diego  CA 

•  Science  Applications  International  Corporation  (SAIC),  San  Diego  CA 

•  Management  and  Technical  Services  (MTS)  Technologies,  San  Diego  CA 

•  Space  and  Naval  Warfare  Systems  Command  (SPAWAR),  San  Diego,  CA 

•  Maritime  Battle  Center  (MBC) 

•  Center  for  Naval  Analyses  (CNA) 


Exercise  Scenario 

The  major  focus  of  this  medical  exercise  was  to  evaluate  the  ability  of  JMO-T  ACTD  to 
detect  and  to  subsequently  analyze  a  potential  bio-warfare  event.  In  order  to  do  this,  the 
exercise  scenario  was  divided  into  two  pieces,  one  involving  military  injured  and  DNBI 
patients  and  the  second  involving  significant  number  of  sick  civilian  refugees. 

The  refugee  scenario  piece  involved  a  total  of  —75,000  refugees  (total)  divided  among 
five  camps:  Camp  Teal  #1,  Camp  Teal  #2,  Camp  Teal  #3,  Camp  Grey  #1,  and  Camp 
Grey  #2.  Country  Teal  and  Country  Grey  were  nominally  neutral  countries  that  were  not 
otherwise  active  in  the  overall  FBE-I  exercise  scenario. 


Using  real  World  Health  Organization  (WHO)  surveillance  data  on  specific  diseases  (as 
recorded  from  recent  events  in  East  Timor),  the  most  frequent  five  diseases  were  chosen 
for  use  in  the  refugee  camp  portion  of  this  scenario.  These  included  upper  respiratory 
infection  (URI),  lower  respiratory  infection  (LRI),  malaria,  diarrhea,  and  diarrhea 
(without  blood).  Measles  was  also  included  in  the  scenario,  because  of  its  ability  to 
spread  disease  and  death  rapidly  in  a  population  of  unvaccinated  children.  The  relative 
frequencies  of  these  diseases  were  calculated  from  the  WHO  data.  These  percentages 
were  then  scaled  to  yield  a  5%  overall  disease  incidence  rate  in  the  population  of  divided 
among  the  five  refugee  camps. 


Patient  files  were  developed  using  the  East  Timor  disease  statistics  for  ten  background 
days  (injected  into  MeWS/  MDSS  prior  to  exercise  start)  and  the  first  three  days  of  FBE- 
I.  Three  epidemics  were  designed  into  the  scenario  database  —  malaria  and  diarrheal 
outbreaks  occurred  in  all  camps  on  the  first  day  of  FBE-I,  with  an  outbreak  of  measles 
occurring  in  Camp  Grey  #1  on  the  second  day.  An  additional  outbreak  of  URI  occurred 
via  message  traffic  only  in  Camp  Teal  #1  on  day  six  of  the  exercise,  which  required  re¬ 
analysis  of  the  original  URI  data  from  all  refugee  camps.  This  structure  was  designed  to 
examine  MDSS  detection  ability  for  epidemics  that  occurred  at  two  different  threshold 
levels  in  addition  to  an  epidemic  “spike”  (low  numbers,  but  high  interest). 

Patient  record  development 

Computerized  patient  records  were  built  using  the  five  diseases  for  the  10  days  of 
background  camp  data.  These  records  contained  a  subset  of  standardized  medical 
information  (that  MeWS  and  MDSS  data  structures  support)  including: 


•  MTF 

•  SSN 

•  DOB 

•  Last  name 

•  First  name 

•  Branch 

•  Unit 

•  Command 

•  Gender 

•  Nationality 

•  Event  location 

•  Primary  diagnosis 

•  Primary  ICD9  code 

•  Secondary  ICD9  code 

•  DNBI  category 

•  Disposition 

•  GPS  location 

•  Encounter  date 

•  Report  date 

•  Free  text  field 


These  text  fields  were  chosen  to  mirror  the  medical  inject  capability  of  the  Joint  Medical 
Semi-Automated  Forces  (JMedSAF),  which  had  originally  been  scheduled  to  design  the 
patient  populations,  but  was  unable  to  do  so.  It  is  important  to  note  that  standardized 
SAMS  patient  encounters  do  not  contain  the  following  fields:  Primary  Diagnosis, 
Secondary  Diagnosis,  DNBI  category.  Encounter  Type,  Patient  Type,  or  Age. 

The  free  text  field  was  added  to  the  data  structure  of  MeWS  and  MDSS  as  a  way  of 
adding  signs  and  symptoms  for  exercise  purposes.  It  was  originally  anticipated  that  this 
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free  text  field  was  searchable  in  MDSS.  When  this  proved  not  to  be  the  case,  both  the 
primary  diagnosis  and  specific  ICD9  codes  were  also  added  to  each  data  set.  A  similar 
SAMS  specific  function,  the  SOAP  note  (Subjective,  Objective,  Assessment,  Plan  of 
care)  involves  a  free  text  entry  by  the  medical  provider.  The  SOAP  note  is  also  not 
currently  searchable  utilizing  MDSS,  but  is  viewable  in  the  patient  record  review 
function. 

Primary  diagnosis  and  ICD9  codes  were  standardized  for  this  patient  population.  This  is 
not  a  realistic  expectation  in  real  world  operations,  but  it  made  for  a  “cleaner”  experiment 
data  set.  This  also  enabled  MDSS  to  parse  the  patient  files  into  the  specific  DNBI 
categories  (Gastrointestinal,  Respiratory,  Unexplained  fever.  Other),  where  the  statistical 
analyses  occurred. 


Primary  diagnosis 

ICD9  code 

DNBI  Category 

Diarrhea 

558.90 

Gastrointestinal 

Bloody  Diarrhea 

009.30 

Gastrointestinal 

URI 

465.90 

Respiratory 

LRI 

486.00 

Respiratory 

Malaria 

780.60 

Unexplained  Fever 

Measles 

055.90 

Other 

In  addition,  a  matrix  was  set  up  to  provide  a  range  of  clinical  signs  and  symptoms  normal 
for  each  disease.  Each  patient’s  signs/symptoms  were  the  result  of  a  randomized 
selection  from  each  column  of  the  matrix  for  that  disease.  For  example,  one  patient  might 
have  Symptom  Al,  Symptom  B6,  Temperature  4,  and  Blood  Pressure  5  listed  in  the  free 
text  field  of  their  patient  encounter  record.  Note:  this  included  "normal  -  non-diseased" 
symptoms  and  signs  -  not  every  patient  would  show  every  disease  sign  or  symptom. 


Symptom 

Symptom 

Sign 

Sign 

Al 

B1 

Temperature  1 

BPl 

A2 

B2 

Temperature  2 

BP2 

A3 

B3 

Temperature  3 

BP3 

A4 

B4 

Temperature  4 

BP4 

A5 

B5 

Temperature  5 

BPS 

A6 

B6 

Temperature  6 

BP6 

Additional  military  DNBI  patient  files  were  also  developed  using  this  same  file 
generation  strategy.  Approximately  20  DNBI  patient  files  were  provided  for  each  of 
eight  days  of  FBE-I.  No  measles  patients  were  developed;  otherwise,  the  same  diseases 
as  the  refugee  camp  scenario  were  used  (URI,  LRI,  diarrhea,  diarrhea  (with  blood), 
malaria). 
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Wargame  Observations 


One  month  prior  to  FBE-I,  a  preparatory  wargame  was  conducted  on  board  the  USS 
Coronado.  The  purpose  of  this  wargame  was  to  provide  for  systems  integration  and 
operator  training  in  advance  of  FBE-I.  The  observations  that  follow  are  primarily 
concerned  with  problems  encountered  in  the  initial  set  up  and  data  injects  into  JMOT- 
ACTD.  These  arose  partly  because  the  system  is  early  in  its  developmental  cycle. 
Because  most  of  the  wargame  was  tied  up  with  documentation  and  resolution  of  these 
problems,  the  JTF  Surgeon  and  staff  gained  little  experience  with  JMOT-ACTD  prior  to 
FBE-I. 


The  following  issues  lessened  the  operational  effectiveness  of  JMO-T  ACTD  during  the 
FBE-I  Wargame: 

•  Initial  problems  occurred  between  MeWS  and  MDSS  communications  such  that 
the  systems  could  not  exchange  data.  As  a  result,  MDSS  could  not  receive  the 
database  “snapshots”  for  subsequent  analysis  which  MeWS,  as  the  overall 
database  for  JMO-T  ACTD,  would  normally  provide. 

•  MDSS  was  unable  to  parse  the  ICD9  codes  into  their  appropriate  DNBI 
categories.  This  resulted  in  all  patient  files  being  filed  into  the  DNBI  category 
“Other”.  No  detection  nor  additional  analysis  was  possible  until  this  problem  was 
corrected. 

•  After  the  above  parsing  problem  was  fixed,  subsequent  review  of  the  known 
wargane  baseline  data  set  indicated  that  too  many  patients  in  each  disease 
category  were  being  counted  by  MDSS.  This  occurred  because  the  system  was 
counting  all  visits  (initial  and  follow-up)  as  initial  visits,  and  calculated  visit 
statistics  accordingly. 
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Exercise  Observations 


JMO-T  ACTD  /Collaborative  Planning 

Throughout  FBE-I,  JMO-T  ACTD  information  was  used  to  assess  the  current  medical 
readiness  state  of  the  Joint  Task  Force.  Daily  interactions  with  the  CINCPAC  Surgeon 
and  CINCPACFLT  Surgeon,  via  CINC  21  teleconferencing  and  exercise  website  updates, 
also  enabled  a  “near-real  time”  medical  operational  picture  to  be  maintained  at  those 
higher  commands. 

Daily  collaborative  discussions  were  used: 

•  To  review  daily  FBE-I  operational  and  intelligence  information 

•  To  review  and  update  current  force  medical  capabilities  (MeWS  watchboard) 

•  To  review  previous  day’s  data  from  both  military  and  refugee  camps  (MDSS) 

•  To  discuss  significant  medical  events 

•  To  discuss  courses  of  action  (COA)  in  response  to  exercise  MESL  messages 

The  ability  to  conduct  this  teleconferencing  enabled  directed  medical  discussions, 
treatment  recommendations,  and  additional  actions  following: 

•  The  initial  detection  of  a  potential  bio-warfare  incident  in  the  military  population 
on  exercise  day  1 

•  The  initial  assessment  of  the  clinical  signs  and  symptoms  of  24  military  patients 
on  exercise  day  3 

•  The  requests  for  Navy  Environmental  and  Preventative  Medicine  Unit  6 
(NEPMU-6)  assistance,  initially  for  refugee  camps  on  exercise  day  1,  then  for  the 
JTF  itself,  to  provide  on-site  laboratory  testing  and  preventative  medicine 
capabilities 

•  The  request  for  assistance  with  malarial  outbreak  on  exercise  day  1 

•  The  request  for  civilian  epidemiologic  and  laboratory  support  to  Country  Teal 
following  animal  disease  outbreak  on  exercise  day  six 

•  The  requests  by  refugee  camps  for  food  and  medications  throughout  the  exercise. 

There  were  some  problems,  however,  due  to  security  issues  and  communications 
connectivity,  with  use  of  the  system  in  conjunction  with  CINC-21.  These  problems 
resulted  in  less  than  optimal  collaborative  efforts. 

•  JMO-T  ACTD  did  not  have  direct  connectivity  with  the  Joint  Operations  Center 
(JOC)  while  the  teleconferencing  capability  of  CINC-21  was  available  only  in  the 
JOC.  As  a  workaround,  the  JTF  Surgeon  used  MeWS  and  MDSS  screen  shot 
files  while  in  the  JOC.  These  same  files  were  also  sent  to  CINCPAC  in  order  to 
facilitate  discussions.  This  particular  workaround  effectively  limited  the 
teleconference  discussions  to  those  particular  slides.  In  addition,  because  these 
slides  were  consistently  prepared  the  night  before,  prior  to  the  upload  of  current 
day  patient  data,  they  did  not  contain  the  latest  information. 
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•  Additional  problems  were  noted  in  sending  the  screen  shot  files  and  daily  MeWS 
database  snapshots  to  CINCPAC.  Teleconferenced  discussions  held  on  the  first 
three  days  of  the  exercise  were  conducted  without  receipt  of  these  e-mails  (due  to 
a  five  hour  transmission  delay),  again  resulting  in  sub-optimal  discussions. 

•  The  exercise  participants  preferred  the  use  of  audio,  rather  than  text  chat,  during 
their  interactions.  This  preference  resulted  in  significant  use  of  non-secure 
communications  channels  (i.e.  POTS). 

o  CINC-21  was  continually  hampered  by  audio  problems  (transmission  line 
problems,  simultaneous  VTC  usage).  Every  discussion  wasted  between 
25%  and  50%  of  the  available  time  window  attempting  to  regain  audio 
contact  after  its  loss.  This  was  in  spite  of  the  availability  of  text  chat 
throughout  every  session.  As  a  workaround,  the  POTS  line  to  Hawaii  was 
used  during  some  of  the  discussions.  In  a  real-world  situation,  however, 
security  issues  would  likely  preclude  use  of  this  non-secure  capability. 

o  Because  of  the  loss  of  SIPRNET  connectivity,  the  final  collaborative 
discussion  was  not  held  using  CINC-21.  Instead,  it  was  held  entirely  via 
POTS  on  speakerphone,  following  transmission  of  MeWS  data  and 
discussion  slides  to  CINCPAC. 

Neither  operational  security  and  patient  privacy  issues  were  addressed  during  this 
exercise.  In  fact,  numerous  unclassified  POTS  phone  conversations  were  conducted 
during  the  collaborative  planning  sessions  upon  failure  of  CrNC-21  audio  capabilities. 
Both  sets  of  issues  are  crucial  to  the  success  of  this  technology  and  should  be  addressed 
in  future  experiments. 

JMO-T  ACTD  /  JTF  Surgeon  Staffing  levels 

These  technologies  offer  a  significant  amount  of  operational  information  for  analysis. 
The  Deputy  JTF  Surgeon  was  tasked  with  all  MDSS  detection  and  analysis.  This  tasking 
also  included  the  preparation  of  the  information  in  formats  appropriate  for  various  CJTF 
requirements  (exercise  website  updates,  evening  briefings)  and  for  collaborative 
discussions  with  CINCPAC  (powerpoint  slides).  The  JTF  Medical  Planner  was  tasked 
with  all  MeWS  information,  analysis,  and  updates.  This  included  MeWS  watchboard 
data  downloads  in  addition  to  CJTF  information  requirements  and  CINCPAC  discussion 
points. 

Because  none  of  the  detection  or  analysis  tasks  have  been  automated  in  either  MeWS  or 
MDSS,  all  available  information  screens  must  be  manually  reviewed  by  these  operators. 
A  complete  and  standardized  review  alone  is  a  considerable  task. 

Consider,  for  example,  if  MDSS  alerted  on  possible  outbreaks  in  two  different  DNBI 
categories  in  two  different  units  of  a  seven  member  task  force.  In  order  to  detect  any 
alerts,  an  effective  search  approach  might  be  to  look  at  the  over-all  task  force  first,  to  see 
if  any  of  the  15  separate  DNBI  categories  reveal  a  problem.  For  this  example,  that 
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review  would  indicate  that  a  problem  might  be  present  in  two  of  the  categories. 
Additional  analysis  of  these  two  categories  will  then  require  a  review  of  that  category  on 
each  of  the  seven  units,  to  determine  the  specific  problematic  unit(s).  This  surveillance 
strategy  would  require  a  total  of  1 5  +  7  +  7  screen  reviews  before  the  surveillance  task 
could  be  complete.  If  each  review  takes  3  minutes,  almost  90  minutes  would  have  been 
spent  in  just  that  single  day’s  detection  task. 

Other  tasks  in  MDSS  and  MeWS,  in  addition  to  the  detection  task  outlined  above,  might 
also  be  candidates  for  automation.  These  could  include  a  wide  variety  of  standardized 
slide  outputs  (for  briefing  purposes,  website  uploads)  to  facilitate  the  dissemination  of 
information  among  the  various  operational  and  medical  users.  Until  this  level  of 
automation  is  provided  by  the  software,  more  personnel  will  likely  be  required  to  provide  an 
interim  capability. 

JMO-T  ACTD  /  ’’Within  System”  Communications 

This  experiment  also  demonstrated  the  use  of  multiple  communications  (Extending 
Littoral  Battlespace  (ELB)  Wamet,  HF,  SATCOM)  to  transmit  information  from  remote 
sites  into  the  MeWS  database.  Direct  and  prioritized  e-mail  communications  between 
remote  sites  and  the  JTF  Surgeon  were  facilitated  by  the  TCAS  (Team  Care  Automation 
System),  a  specific  MeWS  function.  In  future  operations,  standardized  patient  files 
(similar  to  those  used  for  simulated  patients  in  this  exercise)  could  be  transmitted  using 
this  technology,  including  data  obtained  from  non-military  providers. 

Transmission  of  datafiles  within  JMO-T  ACTD  may  be  best  accomplished  in  a  “packet” 
mode,  as  compared  with  a  live-entry/transmission,  especially  during  a  limited  data 
transmission  window.  The  current  form  of  data  entry  via  end-user  terminal  technology 
(EUT)  may  also  not  be  suitable  for  combat  corpsmen,  but  might  be  more  suitably 
employed  at  higher  echelons  of  care,  again  due  to  operational  time  constraints. 

•  Each  prepared  patient  encounter  file  took  less  than  30  seconds  to  be  uploaded  and 
transmitted  over  the  communications  path  into  the  MeWS  database. 

•  Using  the  end-user  terminals  to  enter  data  directly  was  significantly  more  time 
consuming,  taking  up  to  20  minutes  to  enter  an  entire  file  prior  to  transmission. 

JMO-T  ACTD  /MeWS 


Numerous  functions  in  MeWS  worked  as  “proof  of  concept”  demonstrations  during  the 
experiment  but  require  additional  medical  user  feedback  and  refinement  prior  to 
operational  deployment.  These  included: 


•  Report  capability 

•  Medical  watchboard 

•  Database 
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Functions  which  were  not  demonstrated  during  FBE-I,  but  which  would  be  valuable  to 
the  JTF  Surgeon,  included  the  graphical  display  of  information,  which  was  not  available 
but  is  anticipated  in  the  near  future.  In  addition,  little  capability  was  observed  in 
managing  information  that  may  be  available  through  non-electronic  means.  For  example, 
message  traffic  containing  numerical  refugee  data  could  not  be  entered  into  the 
operational  picture  presented  by  MeWS  or  by  MDSS.  No  feature  exists  in  either  MeWS 
or  MDSS  to  permit  use  of  this  type  of  non-standardized  information. 

JMO-T  ACTD  /MDSS  Alert  and  Detection 

MDSS  correctly  alerted  on  all  three  epidemics  present  in  the  refugee  portion  of  the 
scenario.  These  epidemics  were  structured  to  test  MDSS  alert  capabilities  at  three 
different  threshold  levels.  These  included  “burst”,  at  more  than  3  standard  deviations 
away  from  the  population  mean,  “outlier”,  between  1  and  3  standard  deviations  away 
from  the  population  mean,  and  “spike”,  for  a  disease  where  no  background  population 
data  exists.  Detection  followed  operator  review  of  the  color-coded  bar  graphs  of  ICD-9 
coded  disease  information  as  developed  from  all  camps  and  from  each  single  camp. 

•  The  malaria  epidemic  occurred  on  day  one  with  an  outlier  in  the  data  in  all 
camps.  The  epidemic  increased  to  the  burst  level  on  subsequent  exercise 
days. 

•  The  gastrointestinal  outbreak  occurred  on  day  one  with  a  burst  in  the  patient 
population  data  in  all  refugee  camps.  This  level  of  disease  continued 
throughout  the  next  two  days  of  the  exercise. 

•  Detection  of  the  measles  outbreak  occurred  as  a  spike  of  cases  against  a  non¬ 
existent  background  population  in  two  of  three  of  the  camps. 

Without  the  MDSS  automated  analysis  and  data  presentation,  detection  of  these  three 
epidemics  would  have  required  a  significant  amount  of  time  and  effort  by  the  JTF 
Surgeon’s  staff 

•  Future  developmental  efforts  should  concentrate  on  automation  of  this  detection 
process.  Currently,  detection  depends  upon  complete  operator  review  of  all  the 
available  MDSS  information  looking  at  each  DNBI  category  by  unit  and  by  total 
force.  Instead,  this  information  should  be  combined  into  a  single  daily  alert 
message  for  operator  review. 

In  addition,  while  there  were  lesser  numbers  of  military  patients,  the  first  day’s  data  on 
respiratory  patients  was  immediately  of  interest  to  the  JTF  Surgeon  and  staff 
epidemiologist,  because  it  was  approximately  twice  the  normal  level  (based  on  operator 
experience). 
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JMO-T  ACTD  /MDSS  Analysis 


Detection  occurred  as  the  result  of  MDSS  analysis  of  ICD-9  code  information,  divided 
among  four  DNBI  categories  (fever  of  undetermined  origin,  gastrointestinal  disease, 
respiratory  disease,  other).  This  information  yielded  the  information  that  “something” 
seemed  to  be  a  problem  in  three  of  the  four  DNBI  categories. 

Following  initial  detection  of  an  unusual  medical  event,  the  next  step  in  medicine  relies 
on  the  ability  to  diagnose  disease.  Unfortunately,  on-board  laboratory  capabilities  are 
limited  and  deployable  technical  assistance  will  be  days  in  arriving  on-scene.  As  a  result, 
rapid  analysis  of  signs  and  symptom  information  is  the  most  viable  way  to  determine  a 
differential  diagnosis.  However,  as  currently  configured,  MDSS  provides  no  capability 
to  review  or  to  analyze  patient  records  for  specific  clinical  sign  and  symptoms. 

•  MDSS  contains  an  “Ad  Hoc”  epidemiologic  analysis  tool.  The  purpose  of  this 
tool  is  to  permit  a  more  in-depth  review  of  the  patient  database  and  to  facilitate 
subsequent  user-defined  searches. 

o  The  information  available  in  the  Excel  spreadsheet  does  not  provide  the 
appropriate  level  of  detail  required.  DNBI  category  listing  is  the  sole 
piece  of  medical  diagnostic  information  currently  available  to  the  user 
through  this  function. 

o  Even  ICD-9  code  (final  diagnosis)  information  is  not  contained  in  the 
spreadsheet,  in  spite  of  the  fact  that  statistical  analysis  of  this  information 
results  in  initial  MDSS  alerts. 

•  Patient  records  can  be  reviewed,  individually,  in  MDSS.  SOAP  note  information 
(free  text  consisting  of  Subjective,  Objective,  Assessment,  Plan  of  care 
information)  is  available  at  this  review  level. 

o  SOAP  note  information  is  not  currently  accessible  via  the  Ad  Hoc  analysis 
function. 

o  The  free  text  field  used  to  provide  signs  and  symptoms  in  this  exercise 
was  not  accessible  either  through  the  individual  record  review  function  or 
through  the  Ad  Hoc  analysis  function  in  MDSS. 

Patient  records  developed  for  this  exercise  utilized  a  free  text  field  that  was  only 
accessible  through  the  MeWS  watchboard.  The  JTF  Surgeon  used  a  listing  of  the  Ad 
Hoc  Excel  spreadsheet  data  (names,  units)  to  organize  his  review  of  individual  patient 
records  accessible  through  the  MeWS  watchboard.  This  review  resulted  in  a  differential 
diagnosis  of  tularemia,  a  potential  bio-warfare  agent^.  The  diagnosis  was  based  on  the 
consistent  presence  of  two  specific  clinical  features  indicative  of  tularemia  within  the 


^  Dennis,  DT,  et  al.  200 1 .  Tularemia  as  a  Biological  Weapon.  Journal  of  the  Americal  Medical 
Association.  285((21):2763-2773. 


context  of  these  upper  respiratory  infection  (URI).  Both  conjunctivitis  (red  eyes)  and 
temperature/pulse  dissociation  were  consistently  observed  in  the  majority  of  this  URI 
patient  population: 

•  The  analysis  of  24  upper  respiratory  infection  patients  took  90  minutes. 

Later  in  the  exercise,  intelligence  information  and  specific  host-country  message  traffic 
indicated  that  an  additional  URI  outbreak  was  occurring  in  refugee  camp  Teal  #1. 
Analysis  of  this  outbreak  was  requested,  within  the  context  of  the  13  days  of  data  (6000 
patients)  available  to  the  JTF  Surgeon. 

•  The  manual  workaround  via  MeWS  would  have  taken  approximately  two  weeks 
of  constant  analysis.  ((90  minutes/24  patients)  =  3.75  minutes/patient  X  6000 
patients  =  22500  minutes  =  375  hours  =  15  days) 

•  During  the  exercise,  a  software  work-around  was  developed  to  the  MDSS  Ad  Hoc 
spreadsheet  function  which  enabled  the  download  of  all  available  patient  data, 
including  signs  and  symptoms. 

•  The  JTF  Surgeon  was  then  able  to  analyze  the  6000  patient  records  in  30  minutes. 

•  The  same  differential  diagnosis,  tularemia,  was  also  indicated  based  on  a  similar 
presentation  (conjunctivitis,  temperature/pulse  dissociation)  in  the  refugee  URI 
population. 

JMO-T  ACTD/  MDSS  Miscellaneous 


There  are  a  number  of  additional  refinements  necessary  to  the  data  structures  and 
graphics  outputs  from  MDSS.  More  interaction  between  the  developers  and  operational 
users  is  likely  to  result  in  significant  improvements  in  the  man-machine  interface  and  the 
overall  presentation  of  information. 

•  MDSS  files  are  structured  to  contain  Date  and  Time  together  in  a  single  field. 
This  data  structure  hampers  subsequent  Excel  analysis  and  sorting,  because  each 
report  cannot  be  easily  sorted  by  Date  alone.  Most  epidemiologic  analysis  is  done 
on  a  per/day  basis,  rather  than  by  moment-to-moment  analysis. 

•  Graphical  presentations  are  structured  as  bar  graphs;  Date  is  the  horizontal  (x) 
axis,  numerical  patient  counts  or  patient  rates  are  presented  along  the  vertical  (y) 
axis.  The  bar  graphs  have  been  standardized  into  a  perfect  square.  A  number  of 
problems  arise  from  this  standardization; 

o  The  y-axis  is  divided  evenly  between  the  maximum  value  observed  for 
any  given  data  set  and  zero.  For  data  containing  total  patient  counts,  this 
results  in  data  annotated  with  decimal  (versus  integer)  numbers.  This  is 
inappropriate  and  requires  correction  to  integer  format. 
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o 


The  y-axis  is  not  annotated  if  the  maximum  value  observed  from  the  data 
is  less  than  one.  This  commonly  occurs  during  analysis  of  rate-oriented 
data  and  results  in  a  graph  which  essentially  contains  no  information  due 
to  the  lack  of  an  annotated  y-axis. 

o  No  graphical  output  (y-axis  scale,  x-axis  scale)  can  be  altered  by  the 
operator. 
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